Re: [PATCH 2/2] dma: tegra: fix residual calculation for cyclic case
On Friday 13 July 2012 11:58 AM, Vinod Koul wrote: On Fri, 2012-07-13 at 11:09 +0530, Laxman Dewangan wrote: You didnt get my other mail about applying? Read carefully now and saw both are applied. Thanks for care. Thanks, Laxman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8 v2] i2c:i2c-bfin-twi: TWI fails to restart next transfer in high system load.
On Wed, Jun 13, 2012 at 04:22:44PM +0800, Sonic Zhang wrote:
> From: Sonic Zhang
>
> Current driver was developed based on BF537 0.2 HRM. In high system load,
> BUFRDERR error
> interrupt may be raised if XMTSERV interrupt of last TX byte is not served in
> time
> (set RSTART bit), which breaks restart tranfer as expected.
>
> "Buffer Read Error (BUFRDERR)" description in Blackfin HRM only applys to
> BF537
> rev. < 0.3. In later rev. and later announced Blackfin chips, such as BF527
> and
> BF548, a new TWI master feature "Clock Stretching" is added into the TWI
> controller,
> BUFRDERR interrupt is not triggered after TX FIFO is empty.
>
> This patch sets RSTART bit at the beginning of the first transfer. The SCL
> and SDA
> is hold till XMTSERV interrupt of last TX byte is served. Restart transfer is
> not broken
> in high system load.
>
> Signed-off-by: Sonic Zhang
> ---
> drivers/i2c/busses/i2c-bfin-twi.c | 23 +--
> 1 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-bfin-twi.c
> b/drivers/i2c/busses/i2c-bfin-twi.c
> index 2e59bbd..e75ee91 100644
> --- a/drivers/i2c/busses/i2c-bfin-twi.c
> +++ b/drivers/i2c/busses/i2c-bfin-twi.c
> @@ -99,7 +99,7 @@ static void bfin_twi_handle_interrupt(struct bfin_twi_iface
> *iface,
>*/
> else if (iface->cur_mode == TWI_I2C_MODE_COMBINED)
> write_MASTER_CTL(iface,
> - read_MASTER_CTL(iface) | MDIR | RSTART);
> + read_MASTER_CTL(iface) | MDIR);
> else if (iface->manual_stop)
> write_MASTER_CTL(iface,
> read_MASTER_CTL(iface) | STOP);
> @@ -107,10 +107,10 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
>iface->cur_msg + 1 < iface->msg_num) {
> if (iface->pmsg[iface->cur_msg + 1].flags & I2C_M_RD)
> write_MASTER_CTL(iface,
> - read_MASTER_CTL(iface) | RSTART | MDIR);
> + read_MASTER_CTL(iface) | MDIR);
> else
> write_MASTER_CTL(iface,
> - (read_MASTER_CTL(iface) | RSTART) &
> ~MDIR);
> + read_MASTER_CTL(iface) & ~MDIR);
> }
> }
> if (twi_int_status & RCVSERV) {
> @@ -144,10 +144,10 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
> iface->cur_msg + 1 < iface->msg_num) {
> if (iface->pmsg[iface->cur_msg + 1].flags &
> I2C_M_RD)
> write_MASTER_CTL(iface,
> - read_MASTER_CTL(iface) | RSTART
> | MDIR);
> + read_MASTER_CTL(iface) | MDIR);
> else
> write_MASTER_CTL(iface,
> - (read_MASTER_CTL(iface) |
> RSTART) & ~MDIR);
> + read_MASTER_CTL(iface) & ~MDIR);
> }
> }
> }
> @@ -262,9 +262,10 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
> (0xff << 6)));
> iface->manual_stop = 1;
> }
> - /* remove restart bit and enable master receive */
> - write_MASTER_CTL(iface,
> - read_MASTER_CTL(iface) & ~RSTART);
> + /* remove restart bit before last message */
> + if (iface->cur_msg+1 == iface->msg_num)
Spaces around operators. I fixed it for you.
> + write_MASTER_CTL(iface,
> + read_MASTER_CTL(iface) & ~RSTART);
> } else {
> iface->result = 1;
> write_INT_MASK(iface, 0);
> @@ -321,7 +322,8 @@ static int bfin_twi_do_master_xfer(struct i2c_adapter
> *adap,
> return -EINVAL;
> }
>
> - iface->cur_mode = TWI_I2C_MODE_REPEAT;
> + if (iface->msg_num > 1)
> + iface->cur_mode = TWI_I2C_MODE_REPEAT;
> iface->manual_stop = 0;
> iface->transPtr = pmsg->buf;
> iface->writeNum = iface->readNum = pmsg->len;
> @@ -366,6 +368,7 @@ static int bfin_twi_do_master_xfer(struct i2c_adapter
> *adap,
>
> /* Master enable */
> write_MASTER_CTL(iface, read_MASTER_CTL(iface) | MEN |
> + (iface->msg_num > 1 ? RSTART : 0) |
> ((iface->read_write == I2C_SMBUS_READ) ? MDIR : 0) |
> ((CONFIG_I2C_BLACKFIN_TWI_CLK_KHZ > 100) ? FAST : 0));
> SSYNC();
> @@ -530,7 +533,7 @@ int bfin_
Re: [PATCH 4/8 v2] i2c: i2c-bfin-twi: Tighten condition when failing I2C transfer if MEN bit is reset unexpectedly.
On Wed, Jun 13, 2012 at 04:22:43PM +0800, Sonic Zhang wrote:
> From: Sonic Zhang
>
> In order to mark I2C transfer fail when MEN bit in I2C controller is reset
> unexpeced
"unexpected"
> in MCOMP interrupt, interrupt status bits XMTSERV or RCVSERV should be
> checked.
>
> Master Transfer Complete (MCOMP).
> [1] The initiated master transfer has completed. In the absence of a
> repeat start, the bus has been released.
> [0] The completion of a transfer has not been detected.
>
> Signed-off-by: Sonic Zhang
> ---
> drivers/i2c/busses/i2c-bfin-twi.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-bfin-twi.c
> b/drivers/i2c/busses/i2c-bfin-twi.c
> index a5ab454..2e59bbd 100644
> --- a/drivers/i2c/busses/i2c-bfin-twi.c
> +++ b/drivers/i2c/busses/i2c-bfin-twi.c
> @@ -201,7 +201,8 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
> return;
> }
> if (twi_int_status & MCOMP) {
> - if ((read_MASTER_CTL(iface) & MEN) == 0 &&
> + if (twi_int_status & (XMTSERV|RCVSERV) &&
Spaces around operators.
I fixed both for you.
> + (read_MASTER_CTL(iface) & MEN) == 0 &&
> (iface->cur_mode == TWI_I2C_MODE_REPEAT ||
> iface->cur_mode == TWI_I2C_MODE_COMBINED)) {
> iface->result = -1;
> --
> 1.7.0.4
>
>
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
On Thu, 2012-07-12 at 15:31 +0200, Thomas Gleixner wrote:
> On Thu, 12 Jul 2012, Mike Galbraith wrote:
> > On Thu, 2012-07-12 at 13:43 +0200, Thomas Gleixner wrote:
> > > rawlock points to ...968 and the node_list to ...970.
> > >
> > > struct rt_mutex {
> > > raw_spinlock_t wait_lock;
> > > struct plist_head wait_list;
> > >
> > > The raw_lock pointer of the plist_head is initialized in
> > > __rt_mutex_init() so it points to wait_lock.
> > >
> > > Can you check the offset of wait_list vs. the rt_mutex itself?
> > >
> > > I wouldn't be surprised if it's exactly 8 bytes. And then this thing
> > > looks like a copied lock with stale pointers to hell. Eew.
> >
> > crash> struct rt_mutex -o
> > struct rt_mutex {
> >[0] raw_spinlock_t wait_lock;
> >[8] struct plist_head wait_list;
>
> Bingo, that makes it more likely that this is caused by copying w/o
> initializing the lock and then freeing the original structure.
>
> A quick check for memcpy finds that __btrfs_close_devices() does a
> memcpy of btrfs_device structs w/o initializing the lock in the new
> copy, but I have no idea whether that's the place we are looking for.
Thanks a bunch Thomas. I doubt I would have ever figured out that lala
land resulted from _copying_ a lock. That's one I won't be forgetting
any time soon. Box not only survived a few thousand xfstests 006 runs,
dbench seemed disinterested in deadlocking virgin 3.0-rt.
btrfs still locks up in my enterprise kernel, so I suppose I had better
plug your fix into 3.4-rt and see what happens, and go beat hell out of
virgin 3.0-rt again to be sure box really really survives dbench.
> tglx
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 43baaf0..06c8ced 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -512,6 +512,7 @@ static int __btrfs_close_devices(struct btrfs_fs_devices
> *fs_devices)
> new_device->writeable = 0;
> new_device->in_fs_metadata = 0;
> new_device->can_discard = 0;
> + spin_lock_init(&new_device->io_lock);
> list_replace_rcu(&device->dev_list, &new_device->dev_list);
>
> call_rcu(&device->rcu, free_device);
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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/
Re: [PATCH 1/8 v2] i2c: i2c-bfin-twi: Illegal i2c bus lock upon certain transfer scenarios.
On Wed, Jun 13, 2012 at 04:22:40PM +0800, Sonic Zhang wrote:
> From: Michael Hennerich
>
> For transfer counts > 255 bytes i2c-bfin-twi sets the data
> transfer counter DCNT to 0xFF indicating unlimited transfers.
> It then uses a flag iface->manual_stop to manually issue the STOP
> condition, once the required amount of bytes are received.
>
> We found that on I2C receive operation issuing the STOP condition
> together with a FULL RCV FIFO (2bytes) will cause SDA and SCL be
> constantly driven low.
>
> Temporary workaround until further investigation:
> Discard the RCV FIFO before issuing the STOP condition.
>
> Signed-off-by: Michael Hennerich
> Signed-off-by: Sonic Zhang
All 8 patches applied to next, thanks.
If you want to make my life easier, please state what changed from V1 to
V2. I had to look it up manually which costs time and doesn't make the
patchset look like a low-hanging fruit.
> ---
> drivers/i2c/busses/i2c-bfin-twi.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-bfin-twi.c
> b/drivers/i2c/busses/i2c-bfin-twi.c
> index cdb59e5..33031f0 100644
> --- a/drivers/i2c/busses/i2c-bfin-twi.c
> +++ b/drivers/i2c/busses/i2c-bfin-twi.c
> @@ -131,6 +131,10 @@ static void bfin_twi_handle_interrupt(struct
> bfin_twi_iface *iface,
> iface->transPtr++;
> iface->readNum--;
> } else if (iface->manual_stop) {
> + /* Temporary workaround to avoid possible bus stall -
> + * Flush FIFO before issuing the STOP condition
> + */
> + read_RCV_DATA16(iface);
> write_MASTER_CTL(iface,
> read_MASTER_CTL(iface) | STOP);
> } else if (iface->cur_mode == TWI_I2C_MODE_REPEAT &&
> --
> 1.7.0.4
>
>
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH v3 1/3] acpi : cpu hot-remove returns error when cpu_down() fails
Hi Srivatsa,
2012/07/12 21:32, Srivatsa S. Bhat wrote:
> On 07/12/2012 04:52 PM, Yasuaki Ishimatsu wrote:
>> Even if cpu_down() fails, acpi_processor_remove() continues to remove the
>> cpu.
>> But in this case, it should return error number since some process may run on
>> the cpu. If the cpu has a running process and the cpu is turned the power
>> off,
>> the system may not work well.
>>
>> Signed-off-by: Yasuaki Ishimatsu
>>
>
> Reviewed-by: Srivatsa S. Bhat
Thank you for reviewing.
Thanks,
Yasuaki Ishimatsu
> Regards,
> Srivatsa S. Bhat
>
>> ---
>> drivers/acpi/processor_driver.c | 18 --
>> 1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
>> ===
>> --- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c 2012-06-25
>> 04:53:04.0 +0900
>> +++ linux-3.5-rc4/drivers/acpi/processor_driver.c2012-07-05
>> 21:02:58.711285382 +0900
>> @@ -610,7 +610,7 @@ err_free_pr:
>> static int acpi_processor_remove(struct acpi_device *device, int type)
>> {
>> struct acpi_processor *pr = NULL;
>> -
>> +int ret;
>>
>> if (!device || !acpi_driver_data(device))
>> return -EINVAL;
>> @@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
>> goto free;
>>
>> if (type == ACPI_BUS_REMOVAL_EJECT) {
>> -if (acpi_processor_handle_eject(pr))
>> -return -EINVAL;
>> +ret = acpi_processor_handle_eject(pr);
>> +if (ret)
>> +return ret;
>> }
>>
>> acpi_processor_power_exit(pr, device);
>> @@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd
>>
>> static int acpi_processor_handle_eject(struct acpi_processor *pr)
>> {
>> -if (cpu_online(pr->id))
>> -cpu_down(pr->id);
>> +int ret;
>> +
>> +if (cpu_online(pr->id)) {
>> +ret = cpu_down(pr->id);
>> +if (ret)
>> +return ret;
>> +}
>>
>> arch_unregister_cpu(pr->id);
>> acpi_unmap_lsapic(pr->id);
>> -return (0);
>> +return ret;
>> }
>> #else
>> static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr)
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 2/2] dma: tegra: fix residual calculation for cyclic case
On Fri, 2012-07-13 at 11:09 +0530, Laxman Dewangan wrote: > On Friday 13 July 2012 08:45 AM, Vinod Koul wrote: > > On Mon, 2012-07-02 at 10:02 -0600, Stephen Warren wrote: > >> On 07/02/2012 02:22 AM, Laxman Dewangan wrote: > >>> In cyclic mode of DMA, the byte transferred can be more > >>> than the requested size and in this case, calculating > >>> residuals based on the current position of DMA transfer to > >>> bytes requested i.e. bytes required to transfer to reach > >>> bytes requested from current DMA position. > >>> > >>> Signed-off-by: Laxman Dewangan > >> This makes sense to me, although I wonder if details like this aren't > >> something that the dmaengine core should be handling. > > No core doesn't know anything about the how much you are transferring > > and where you are. That is the driver to calculate and provide. > > Just for confirmation, are you going to apply this patch or do I need to > do anything here. ??? You didnt get my other mail about applying? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3 RESEND] acpi : prevent cpu from becoming online
Hi Toshi,
2012/07/13 1:49, Toshi Kani wrote:
On Thu, 2012-07-12 at 20:40 +0900, Yasuaki Ishimatsu wrote:
Even if acpi_processor_handle_eject() offlines cpu, there is a chance
to online the cpu after that. So the patch closes the window by using
get/put_online_cpus().
Why does the patch change _cpu_up() logic?
The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
does not change it, there is the following race.
hot-remove cpu | _cpu_up()
-
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus()|
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu()|
call acpi_unmap_lsapic() |
call put_online_cpus()|
| start and continue _cpu_up()
return acpi_processor_remove()|
continue hot-remove the cpu|
So _cpu_up() can continue to itself. And hot-remove cpu can also continue
itself. If the patch changes _cpu_up() logic, the race disappears as below:
hot-remove cpu | _cpu_up()
---
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus()|
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu()|
call acpi_unmap_lsapic() |
cpu's cpu_present is set |
to false by set_cpu_present()|
call put_online_cpus()|
| start _cpu_up()
| check cpu_present() and return -EINVAL
return acpi_processor_remove()|
continue hot-remove the cpu|
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/processor_driver.c | 14 ++
kernel/cpu.c|8 +---
2 files changed, 19 insertions(+), 3 deletions(-)
Index: linux-3.5-rc6/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc6.orig/drivers/acpi/processor_driver.c 2012-07-12
20:34:29.438289841 +0900
+++ linux-3.5-rc6/drivers/acpi/processor_driver.c 2012-07-12
20:39:29.190542257 +0900
@@ -850,8 +850,22 @@ static int acpi_processor_handle_eject(s
return ret;
}
+ get_online_cpus();
+ /*
+* The cpu might become online again at this point. So we check whether
+* the cpu has been onlined or not. If the cpu became online, it means
+* that someone wants to use the cpu. So acpi_processor_handle_eject()
+* returns -EAGAIN.
+*/
+ if (unlikely(cpu_online(pr->id))) {
+ put_online_cpus();
+ printk(KERN_WARNING "Failed to remove CPU %d, "
+ "since someone onlines the cpu\n" , pr->id);
pr_warn() should be used per the recent checkpatch change.
O.K. I'll update it.
Thanks,
Yasuaki Ishimatsu
Thanks,
-Toshi
+ return -EAGAIN;
+ }
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
+ put_online_cpus();
return ret;
}
#else
Index: linux-3.5-rc6/kernel/cpu.c
===
--- linux-3.5-rc6.orig/kernel/cpu.c 2012-07-12 20:34:29.438289841 +0900
+++ linux-3.5-rc6/kernel/cpu.c 2012-07-12 20:34:35.040219535 +0900
@@ -343,11 +343,13 @@ static int __cpuinit _cpu_up(unsigned in
unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
struct task_struct *idle;
- if (cpu_online(cpu) || !cpu_present(cpu))
- return -EINVAL;
-
cpu_hotplug_begin();
+ if (cpu_online(cpu) || !cpu_present(cpu)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
idle = idle_thread_get(cpu);
if (IS_ERR(idle)) {
ret = PTR_ERR(idle);
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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 v3 1/3] acpi : cpu hot-remove returns error when cpu_down() fails
Hi Toshi,
2012/07/13 1:48, Toshi Kani wrote:
On Thu, 2012-07-12 at 20:22 +0900, Yasuaki Ishimatsu wrote:
Even if cpu_down() fails, acpi_processor_remove() continues to remove the cpu.
But in this case, it should return error number since some process may run on
the cpu. If the cpu has a running process and the cpu is turned the power off,
the system may not work well.
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/processor_driver.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c 2012-06-25
04:53:04.0 +0900
+++ linux-3.5-rc4/drivers/acpi/processor_driver.c 2012-07-05
21:02:58.711285382 +0900
@@ -610,7 +610,7 @@ err_free_pr:
static int acpi_processor_remove(struct acpi_device *device, int type)
{
struct acpi_processor *pr = NULL;
-
+ int ret;
if (!device || !acpi_driver_data(device))
return -EINVAL;
@@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
goto free;
if (type == ACPI_BUS_REMOVAL_EJECT) {
- if (acpi_processor_handle_eject(pr))
- return -EINVAL;
+ ret = acpi_processor_handle_eject(pr);
+ if (ret)
+ return ret;
}
acpi_processor_power_exit(pr, device);
@@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd
static int acpi_processor_handle_eject(struct acpi_processor *pr)
{
- if (cpu_online(pr->id))
- cpu_down(pr->id);
+ int ret;
+
+ if (cpu_online(pr->id)) {
+ ret = cpu_down(pr->id);
+ if (ret)
+ return ret;
+ }
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
- return (0);
+ return ret;
ret is uninitialized when !cpu_online().
Oops! I'll update it.
Thanks,
Yasuaki Ishimatsu
Thanks,
-Toshi
}
#else
static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr)
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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-acpi" 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 v3 2/3 RESEND] acpi : prevent cpu from becoming online
2012/07/12 21:41, Srivatsa S. Bhat wrote:
> On 07/12/2012 05:10 PM, Yasuaki Ishimatsu wrote:
>> Even if acpi_processor_handle_eject() offlines cpu, there is a chance
>> to online the cpu after that. So the patch closes the window by using
>> get/put_online_cpus().
>>
>> Why does the patch change _cpu_up() logic?
>>
>> The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
>> does not change it, there is the following race.
>>
>> hot-remove cpu | _cpu_up()
>> -
>> call acpi_processor_handle_eject() |
>> call cpu_down() |
>> call get_online_cpus()|
>> | call cpu_hotplug_begin() and stop
>> here
>> call arch_unregister_cpu()|
>> call acpi_unmap_lsapic() |
>> call put_online_cpus()|
>> | start and continue _cpu_up()
>> return acpi_processor_remove()|
>> continue hot-remove the cpu|
>>
>> So _cpu_up() can continue to itself. And hot-remove cpu can also continue
>> itself. If the patch changes _cpu_up() logic, the race disappears as below:
>>
>> hot-remove cpu | _cpu_up()
>> ---
>> call acpi_processor_handle_eject() |
>> call cpu_down() |
>> call get_online_cpus()|
>> | call cpu_hotplug_begin() and stop
>> here
>> call arch_unregister_cpu()|
>> call acpi_unmap_lsapic() |
>>cpu's cpu_present is set |
>>to false by set_cpu_present()|
>> call put_online_cpus()|
>> | start _cpu_up()
>> | check cpu_present() and return
>> -EINVAL
>> return acpi_processor_remove()|
>> continue hot-remove the cpu|
>>
>> Signed-off-by: Yasuaki Ishimatsu
>>
>
> Please consider fixing the grammar issue below (since it is a user-visible
> print statement). Other than that, everything looks fine.
>
> Reviewed-by: Srivatsa S. Bhat
>
>> ---
>> drivers/acpi/processor_driver.c | 14 ++
>> kernel/cpu.c|8 +---
>> 2 files changed, 19 insertions(+), 3 deletions(-)
>>
>> Index: linux-3.5-rc6/drivers/acpi/processor_driver.c
>> ===
>> --- linux-3.5-rc6.orig/drivers/acpi/processor_driver.c 2012-07-12
>> 20:34:29.438289841 +0900
>> +++ linux-3.5-rc6/drivers/acpi/processor_driver.c2012-07-12
>> 20:39:29.190542257 +0900
>> @@ -850,8 +850,22 @@ static int acpi_processor_handle_eject(s
>> return ret;
>> }
>>
>> +get_online_cpus();
>> +/*
>> + * The cpu might become online again at this point. So we check whether
>> + * the cpu has been onlined or not. If the cpu became online, it means
>> + * that someone wants to use the cpu. So acpi_processor_handle_eject()
>> + * returns -EAGAIN.
>> + */
>> +if (unlikely(cpu_online(pr->id))) {
>> +put_online_cpus();
>> +printk(KERN_WARNING "Failed to remove CPU %d, "
>> + "since someone onlines the cpu\n" , pr->id);
>
> How about:
> "Failed to remove CPU %d, because some other task brought the CPU back
> online\n"
Looks good to me. I'll update it.
Thanks,
Yasuaki Ishimatsu
>
> Regards,
> Srivatsa S. Bhat
>
>> +return -EAGAIN;
>> +}
>> arch_unregister_cpu(pr->id);
>> acpi_unmap_lsapic(pr->id);
>> +put_online_cpus();
>> return ret;
>> }
>> #else
>> Index: linux-3.5-rc6/kernel/cpu.c
>> ===
>> --- linux-3.5-rc6.orig/kernel/cpu.c 2012-07-12 20:34:29.438289841 +0900
>> +++ linux-3.5-rc6/kernel/cpu.c 2012-07-12 20:34:35.040219535 +0900
>> @@ -343,11 +343,13 @@ static int __cpuinit _cpu_up(unsigned in
>> unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
>> struct task_struct *idle;
>>
>> -if (cpu_online(cpu) || !cpu_present(cpu))
>> -return -EINVAL;
>> -
>> cpu_hotplug_begin();
>>
>> +if (cpu_online(cpu) || !cpu_present(cpu)) {
>> +ret = -EINVAL;
>> +goto out;
>> +}
>> +
>> idle = idle_thread_get(cpu);
>> if (IS_ERR(idle)) {
>> ret = PTR_ERR(idle);
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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-i
Re: [PATCH RFC V3 2/3] kvm: Note down when cpu relax intercepted or pause loop exited
On 13/07/12 05:35, Raghavendra K T wrote: > Yes! I forgot about archs in init function. > How about having > #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT > vcpu->ple.cpu_relax_intercepted = false; > vcpu->ple.dy_eligible = false; > #endif > > This would solve all the problem. No, you need to mask all places > >>> >>> r = kvm_arch_vcpu_init(vcpu); >>> if (r< 0) >>> @@ -1577,6 +1579,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me) >>> int pass; >>> int i; >>> >>> +me->ple.cpu_relax_intercepted = true; >> >> dito > > currently vcpu_on_spin is used only by x86 and s390. so if some other > arch in future uses vcpu_on_spin, I believe they also have to enable > CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT > what do you think? ...because this function is compiled no matter if called or not. > >> maybe define static inline access functions in kvm_host.h that are no-ops >> if CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT is not set. As I already said, can you have a look at using access functions? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MAINTAINERS: bounces, remove or update?
The @smsc.com email address is bouncing. Should it be removed from MAINTAINERS or switched to this @shawell.net address? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] Time fixes and cleanups for 3.6
Looks sensible. Reviewed-by: Ingo Molnar Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] time: Move arch_gettimeoffset() usage into timekeeping_get_ns()
* John Stultz wrote: > + nsec >>= timekeeper.shift; > + > + /* If arch requires, add in gettimeoffset() */ > + nsec += arch_gettimeoffset(); > + return nsec; As a factoring out bonus, this could be further shortened to: return nsec + arch_gettimeoffset(); > + /* If arch requires, add in gettimeoffset() */ > + nsec += arch_gettimeoffset(); > + return nsec; Ditto. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
On 五, 2012-07-13 at 15:08 +0900, Alex Courbot wrote: > On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote: > > As of now, we are getting the definitions done through the platform layer > > data. Considerations for device tree .. yes.. but I do not have any sample > > implementation.. > > Maybe we can help with that then, since we are going to need it. > > > On the public tree: > > Rui is trying to get a public tree from where we can pull Thermal subsystem > > changes; and submit patches against this tree. > > > > I hope Rui will publish the link very soon :-) > > Excellent. Could you keep us posted when this happens? > sure. I'm just working on a patch set and I hope to push them to git.kernel.org by next week. thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] time: Refactor accumulation of nsecs to secs
* John Stultz wrote: > +} > + > + > +/** Stray newline added here as well. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to use the generic thermal sysfs.
On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote: As of now, we are getting the definitions done through the platform layer data. Considerations for device tree .. yes.. but I do not have any sample implementation.. Maybe we can help with that then, since we are going to need it. On the public tree: Rui is trying to get a public tree from where we can pull Thermal subsystem changes; and submit patches against this tree. I hope Rui will publish the link very soon :-) Excellent. Could you keep us posted when this happens? Thanks! Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] time: Move xtime_nsec adjustment underflow handling timekeeping_adjust
* John Stultz wrote: > When we make adjustments speeding up the clock, its possible > for xtime_nsec to underflow. We already handle this properly, > but we do so from update_wall_time() instead of the more logical > timekeeping_adjust(), where the possible underflow actually > occurs. > > Thus, move the correction logic to the timekeeping_adjust, which > is the function that causes the issue. Making update_wall_time() > more readable. > > CC: Ingo Molnar > CC: Peter Zijlstra > CC: Richard Cochran > CC: Prarit Bhargava > CC: Thomas Gleixner > Signed-off-by: John Stultz > --- > kernel/time/timekeeping.c | 42 +- > 1 file changed, 21 insertions(+), 21 deletions(-) > > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > index dd119355..4b76432 100644 > --- a/kernel/time/timekeeping.c > +++ b/kernel/time/timekeeping.c > @@ -987,6 +987,27 @@ static void timekeeping_adjust(s64 offset) > timekeeper.xtime_nsec -= offset; > timekeeper.ntp_error -= (interval - offset) << > timekeeper.ntp_error_shift; > + > + /* > + * It may be possible that when we entered this function, xtime_nsec > + * was very small. Further, if we're slightly speeding the clocksource > + * in the code above, its possible the required corrective factor to > + * xtime_nsec could cause it to underflow. s/slightly speeding/slightly speeding up ? > + * > + * Now, since we already accumulated the second, cannot simply roll > + * the accumulated second back, since the NTP subsystem has been s/cannot/we cannot ? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL for v3.5-rc7] media fixes
Hi Linus, Plese pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for the fixes for the media subsystem, including: - Some regression fixes at the audio part for devices with cx23885/cx25840; - A DMA corruption fix at cx231xx; - two fixes at the winbond IR driver; - Several fixes for the EXYNOS media driver (s5p); - two fixes at the OMAP3 preview driver; - one fix at the dvb core failure path; - an include missing (slab.h) at smiapp-core causing compilation breakage; - em28xx was not loading the IR driver driver anymore. PS.: I'll be out next week due to holidays. Thanks! Mauro Latest commit at the branch: ec3ed85f926f4e900bc48cec6e72abbe6475321f [media] Revert "[media] V4L: JPEG class documentation corrections" The following changes since commit 099987f0aaf28771261b91a41240b9228f2e32b2: [media] smia: Fix compile failures (2012-06-18 19:52:05 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to ec3ed85f926f4e900bc48cec6e72abbe6475321f: [media] Revert "[media] V4L: JPEG class documentation corrections" (2012-07-07 00:12:50 -0300) Anton Blanchard (3): [media] cx23885: Silence unknown command warnings [media] winbond-cir: Fix txandrx module info [media] winbond-cir: Initialise timeout, driver_type and allowed_protos David Dillow (1): [media] cx231xx: don't DMA to random addresses Devin Heitmueller (6): [media] cx25840: fix regression in HVR-1800 analog support [media] cx25840: fix regression in analog support hue/saturation controls [media] cx25840: fix regression in HVR-1800 analog audio [media] cx25840: fix vsrc/hsrc usage on cx23888 designs [media] cx23885: make analog support work for HVR_1250 (cx23885 variant) [media] cx23885: add support for HVR-1255 analog (cx23888 variant) Fengguang Wu (1): [media] pms: fix build error in pms_probe() Kamil Debski (1): [media] s5p-mfc: Fixed setup of custom controls in decoder and encoder Laurent Pinchart (2): [media] omap3isp: preview: Fix output size computation depending on input format [media] omap3isp: preview: Fix contrast and brightness handling Mauro Carvalho Chehab (2): [media] smiapp-core: fix compilation build error [media] em28xx: fix em28xx-rc load Randy Dunlap (1): [media] media: pms.c needs linux/slab.h Sachin Kamat (2): [media] s5p-fimc: Fix compiler warning in fimc-lite.c [media] s5p-fimc: Stop media entity pipeline if fimc_pipeline_validate fails Sakari Ailus (1): [media] s5p-fimc: media_entity_pipeline_start() may fail Santosh Nayak (1): [media] dvb-core: Release semaphore on error path dvb_register_device() Sylwester Nawrocki (10): [media] s5p-fimc: Fix bug in capture node open() [media] s5p-fimc: Don't create multiple active links to same sink entity [media] s5p-fimc: Honour sizeimage in VIDIOC_S_FMT [media] s5p-fimc: Remove superfluous checks for buffer type [media] s5p-fimc: Prevent lock-up in multiple sensor systems [media] s5p-fimc: Fix fimc-lite system wide suspend procedure [media] s5p-fimc: Shorten pixel formats description [media] s5p-fimc: Update to the control handler lock changes [media] s5p-fimc: Add missing FIMC-LITE file operations locking [media] Revert "[media] V4L: JPEG class documentation corrections" Documentation/DocBook/media/v4l/controls.xml |2 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 -- drivers/media/dvb/dvb-core/dvbdev.c|1 + drivers/media/rc/winbond-cir.c |4 +- drivers/media/video/cx231xx/cx231xx-audio.c|4 +- drivers/media/video/cx231xx/cx231xx-vbi.c |2 +- drivers/media/video/cx23885/cx23885-cards.c| 89 +--- drivers/media/video/cx23885/cx23885-dvb.c |6 ++ drivers/media/video/cx23885/cx23885-video.c|9 +- drivers/media/video/cx23885/cx23885.h |1 + drivers/media/video/cx25840/cx25840-core.c | 76 - drivers/media/video/em28xx/em28xx-cards.c |2 +- drivers/media/video/omap3isp/isppreview.c |6 +- drivers/media/video/pms.c |2 + drivers/media/video/s5p-fimc/fimc-capture.c| 69 --- drivers/media/video/s5p-fimc/fimc-core.c | 19 +++-- drivers/media/video/s5p-fimc/fimc-lite.c | 73 +++- drivers/media/video/s5p-fimc/fimc-mdevice.c| 48 +-- drivers/media/video/s5p-fimc/fimc-mdevice.h|2 - drivers/media/video/s5p-mfc/s5p_mfc_dec.c |1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c
Re: [PATCH 4/8] time: Condense timekeeper.xtime into xtime_sec
* John Stultz wrote:
> +static void tk_set_xtime(struct timekeeper *tk, const struct timespec *ts)
> +{
> + tk->xtime_sec = ts->tv_sec;
> + tk->xtime_nsec = ts->tv_nsec << tk->shift;
> +}
> +
> +
> +static void tk_xtime_add(struct timekeeper *tk, const struct timespec *ts)
Small nit: there's a stray newline here.
> +{
> + tk->xtime_sec += ts->tv_sec;
> + tk->xtime_nsec += ts->tv_nsec << tk->shift;
> +}
> +
>
> /**
Ditto.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] ntp: Fix STA_INS/DEL clearing bug
* John Stultz wrote: > From: John Stultz > > In commit 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d, I > introduced a bug that kept the STA_INS or STA_DEL bit > from being cleared from time_status via adjtimex() > without forcing STA_PLL first. > > Usually once the STA_INS is set, it isn't cleared > until the leap second is applied, so its unlikely this > affected anyone. However during testing I noticed it > took some effort to cancel a leap second once STA_INS > was set. > > This issue affects 3.4 and up. > > Since this isn't urgent (issue is only observed in testing, > the behavior doesn't affect ntpd, nor is a leapsecond due > for at least ~6 months), and we're late in the 3.5-rc > cycle, I'm holding this off for 3.6 merge window, > where I'll then backport to 3.5-stable and 3.4-stable. > CC: sta...@vger.kernel.org We generally don't do such a workflow. Either it's valid for tip:timers/urgent and it can have a -stable tag, or it should not be backported, and not have a -stable tag. The rule is: if it's important enough for -stable then it's doubly important for the current -rc kernel! Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] time: Refactor accumulation of nsecs to secs
* John Stultz wrote: > We do the exact same logic moving nsecs to secs in the > timekeeper in multiple places, so condense this into a > single function. > > CC: Ingo Molnar > CC: Peter Zijlstra > CC: Richard Cochran > CC: Prarit Bhargava > CC: Thomas Gleixner Please make that Cc:, not CC:. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
> -Original Message- > From: Alex Courbot [mailto:acour...@nvidia.com] > Sent: Friday, July 13, 2012 11:19 AM > To: R, Durgadoss > Cc: Wei Ni; Zhang, Rui; Brown, Len; a...@linux-foundation.org; khali@linux- > fr.org; j...@perches.com; linux-kernel@vger.kernel.org; linux- > te...@ger.kernel.org > Subject: Re: How to use the generic thermal sysfs. > > On 07/12/2012 07:54 PM, R, Durgadoss wrote: > > We are working on a notification API from any generic sensor driver to > > the thermal framework. > > Please have a look at the 'notify_thermal_framework' API in the patch here: > > http://www.spinics.net/lists/linux-acpi/msg36049.html > > At first sight these patches look close to what we need as well. Are you > considering to support the definitions of thermal zones using the device > tree? Is there a public git tree where we can pull the latest version of > this code in order to keep in sync with you guys? As of now, we are getting the definitions done through the platform layer data. Considerations for device tree .. yes.. but I do not have any sample implementation.. On the public tree: Rui is trying to get a public tree from where we can pull Thermal subsystem changes; and submit patches against this tree. I hope Rui will publish the link very soon :-) Thanks, Durga
Re: [PATCH net-next 4/8] wireless: Use eth_random_addr
--- On Fri, 13/7/12, Joe Perches wrote:
> From: Joe Perches
> Subject: [PATCH net-next 4/8] wireless: Use eth_random_addr
> To: "David Miller" , "John W. Linville"
> , "Christian Lamparter" ,
> "Ivo van Doorn" , "Gertjan van Wingerde"
> , "Helmut Schaa" , "Herton
> Ronaldo Krzesinski" , "Hin-Tak Leung"
> , "Larry Finger"
> Cc: "Johannes Berg" ,
> linux-wirel...@vger.kernel.org, net...@vger.kernel.org,
> linux-kernel@vger.kernel.org, us...@rt2x00.serialmonkey.com
> Date: Friday, 13 July, 2012, 6:33
> Convert the existing uses of
> random_ether_addr to
> the new eth_random_addr.
>
> Signed-off-by: Joe Perches
Acked-by: Hin-Tak Leung
Would it make sense to have a "check & set" macro?
> ---
> drivers/net/wireless/adm8211.c
> | 2 +-
> drivers/net/wireless/p54/eeprom.c
> | 2 +-
> drivers/net/wireless/rt2x00/rt2400pci.c
> | 2 +-
> drivers/net/wireless/rt2x00/rt2500pci.c
> | 2 +-
> drivers/net/wireless/rt2x00/rt2500usb.c
> | 2 +-
> drivers/net/wireless/rt2x00/rt2800lib.c
> | 2 +-
> drivers/net/wireless/rt2x00/rt61pci.c
> | 2 +-
> drivers/net/wireless/rt2x00/rt73usb.c
> | 2 +-
> drivers/net/wireless/rtl818x/rtl8180/dev.c | 2
> +-
> drivers/net/wireless/rtl818x/rtl8187/dev.c | 2
> +-
> 10 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/adm8211.c
> b/drivers/net/wireless/adm8211.c
> index 97afcec..689a71c 100644
> --- a/drivers/net/wireless/adm8211.c
> +++ b/drivers/net/wireless/adm8211.c
> @@ -1854,7 +1854,7 @@ static int __devinit
> adm8211_probe(struct pci_dev *pdev,
> if (!is_valid_ether_addr(perm_addr)) {
> printk(KERN_WARNING
> "%s (adm8211): Invalid hwaddr in EEPROM!\n",
>
> pci_name(pdev));
> -
> random_ether_addr(perm_addr);
> +
> eth_random_addr(perm_addr);
> }
> SET_IEEE80211_PERM_ADDR(dev,
> perm_addr);
>
> diff --git a/drivers/net/wireless/p54/eeprom.c
> b/drivers/net/wireless/p54/eeprom.c
> index 636daf2..1403709 100644
> --- a/drivers/net/wireless/p54/eeprom.c
> +++ b/drivers/net/wireless/p54/eeprom.c
> @@ -857,7 +857,7 @@ good_eeprom:
>
>
> wiphy_warn(dev->wiphy,
>
> "Invalid hwaddr! Using randomly generated
> MAC addr\n");
> -
> random_ether_addr(perm_addr);
> +
> eth_random_addr(perm_addr);
>
> SET_IEEE80211_PERM_ADDR(dev, perm_addr);
> }
>
> diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c
> b/drivers/net/wireless/rt2x00/rt2400pci.c
> index 5e6b501..8b9dbd7 100644
> --- a/drivers/net/wireless/rt2x00/rt2400pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2400pci.c
> @@ -1455,7 +1455,7 @@ static int
> rt2400pci_validate_eeprom(struct rt2x00_dev *rt2x00dev)
> */
> mac = rt2x00_eeprom_addr(rt2x00dev,
> EEPROM_MAC_ADDR_0);
> if (!is_valid_ether_addr(mac)) {
> -
> random_ether_addr(mac);
> +
> eth_random_addr(mac);
> EEPROM(rt2x00dev,
> "MAC: %pM\n", mac);
> }
>
> diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c
> b/drivers/net/wireless/rt2x00/rt2500pci.c
> index 136b849..d2cf8a4 100644
> --- a/drivers/net/wireless/rt2x00/rt2500pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2500pci.c
> @@ -1585,7 +1585,7 @@ static int
> rt2500pci_validate_eeprom(struct rt2x00_dev *rt2x00dev)
> */
> mac = rt2x00_eeprom_addr(rt2x00dev,
> EEPROM_MAC_ADDR_0);
> if (!is_valid_ether_addr(mac)) {
> -
> random_ether_addr(mac);
> +
> eth_random_addr(mac);
> EEPROM(rt2x00dev,
> "MAC: %pM\n", mac);
> }
>
> diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c
> b/drivers/net/wireless/rt2x00/rt2500usb.c
> index 669aecd..3aae36b 100644
> --- a/drivers/net/wireless/rt2x00/rt2500usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2500usb.c
> @@ -1352,7 +1352,7 @@ static int
> rt2500usb_validate_eeprom(struct rt2x00_dev *rt2x00dev)
> */
> mac = rt2x00_eeprom_addr(rt2x00dev,
> EEPROM_MAC_ADDR_0);
> if (!is_valid_ether_addr(mac)) {
> -
> random_ether_addr(mac);
> +
> eth_random_addr(mac);
> EEPROM(rt2x00dev,
> "MAC: %pM\n", mac);
> }
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
> b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 068276e..d857d55 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -4340,7 +4340,7 @@ int rt2800_validate_eeprom(struct
> rt2x00_dev *rt2x00dev)
> */
> mac = rt2x00_eeprom_addr(rt2x00dev,
> EEPROM_MAC_ADDR_0);
> if (!is_valid_ether_addr(mac)) {
> -
> random_ether_addr(mac);
> +
> eth_random_addr(mac);
> EEPROM(rt2x00dev,
> "MAC: %pM\n", mac);
> }
>
> diff --git a/drivers/net/wireless/rt2x00/rt61pci.c
> b/drivers/net/wireless/rt2x00/rt61pci.c
> index ee22bd7..f322596 100644
> --- a/drivers/net/wireless/rt2x00/rt61pci.c
> +++ b/drivers/net/wireless/rt2x00/rt61pci.c
> @@ -2415,7 +2415,7 @@ static int
> rt61pci_validate_eeprom(
Re: [PATCH 0/3] fs/ufs: stop using write_supers and s_dirt
On Thu, 2012-07-12 at 22:45 -0700, Andrew Morton wrote: > checkpatch does not report on context lines - only on added lines. Hmm, I think I saw it ding this in the past. Anyway, I have no problems cleaning at lease white-spaces in UFS globally separately. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
linux-next: Tree for July 13
Hi all, Changes since 20120712: The ext4 tree still has its build failure so I used the version from next-20120709. The tty tree gained a build failure, so I used the version from next-20120712. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. The arm-soc tree lost a conflict. The clk tree gained a conflict against the arm-soc tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 197 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (918227b Merge tag 'fbdev-fixes-for-3.5-2' of git://github.com/schandinat/linux-2.6) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1) Merging arm-current/fixes (ff081e0 ARM: 7457/1: smp: Fix suspicious RCU originating from cpu_die()) Merging m68k-current/for-linus (d8ce726 m68k: Use generic strncpy_from_user(), strlen_user(), and strnlen_user()) Merging powerpc-merge/merge (50fb31c tty/hvc_opal: Fix debug function name) Merging sparc/master (d55de60 sparc64: remove unused function straddles_64bit_va_hole()) Merging net/master (7ac2908 sch_sfb: Fix missing NULL check) Merging sound-current/for-linus (9e9b594 ALSA: usb-audio: Fix the first PCM interface assignment) Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging wireless/master (8a70e7f NFC: NCI module license 'unspecified' taints kernel) Merging driver-core.current/driver-core-linus (5becfb1 kmsg: merge continuation records while printing) Merging tty.current/tty-linus (6b16351 Linux 3.5-rc4) Merging usb.current/usb-linus (dbf0e4c PCI: EHCI: fix crash during suspend on ASUS computers) Merging staging.current/staging-linus (6887a41 Linux 3.5-rc5) Merging char-misc.current/char-misc-linus (16a50b1 mei: pci_resume: set IRQF_ONESHOT for msi request_threaded_irq) Merging input-current/for-linus (cc71a7e Input: xpad - add signature for Razer Onza Tournament Edition) Merging md-current/for-linus (1068411 md/raid10: fix careless build error) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (c475c06 hwrng: atmel-rng - fix data valid check) Merging ide/master (39a50b4 Merge branch 'hfsplus') Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging arm/for-next (dea2ea3 Merge branches 'audit', 'delay', 'dmaengi
Re: How to use the generic thermal sysfs.
On 07/12/2012 07:54 PM, R, Durgadoss wrote: We are working on a notification API from any generic sensor driver to the thermal framework. Please have a look at the 'notify_thermal_framework' API in the patch here: http://www.spinics.net/lists/linux-acpi/msg36049.html At first sight these patches look close to what we need as well. Are you considering to support the definitions of thermal zones using the device tree? Is there a public git tree where we can pull the latest version of this code in order to keep in sync with you guys? Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 0/4] hfsplus: stop using write_supers and s_dirt
On Thu, 2012-07-12 at 16:09 -0700, Andrew Morton wrote: > I really do dislike dropping patches and replacing them. For a whole > bunch of reasons. One of which is that a wholesale replacement > requires a full re-review. Another is that wholesale replacement makes > it hard to see what was changed. I will keep this in mind and in future will send you incremental changes instead. Apologies Andrew. > This latest patchset is identical to the code which is presently in -mm. I am now away and cannot easily send you a diff between v2 and v3, but it really does have changes - exactly as I described - checkpatch.pl fixes (spaces replaced by tabs) and one line removed. Sorry for confusion, I really should have sent an incremental patch. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/2] dma: tegra: fix residual calculation for cyclic case
On Friday 13 July 2012 08:45 AM, Vinod Koul wrote: On Mon, 2012-07-02 at 10:02 -0600, Stephen Warren wrote: On 07/02/2012 02:22 AM, Laxman Dewangan wrote: In cyclic mode of DMA, the byte transferred can be more than the requested size and in this case, calculating residuals based on the current position of DMA transfer to bytes requested i.e. bytes required to transfer to reach bytes requested from current DMA position. Signed-off-by: Laxman Dewangan This makes sense to me, although I wonder if details like this aren't something that the dmaengine core should be handling. No core doesn't know anything about the how much you are transferring and where you are. That is the driver to calculate and provide. Just for confirmation, are you going to apply this patch or do I need to do anything here. Thanks, Laxman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/3] regulator: tps65217: Add device tree support
Hi Mark, On Thu, Jul 12, 2012 at 22:58:37, Mark Brown wrote: > On Tue, Jul 10, 2012 at 04:39:42PM +0530, AnilKumar Ch wrote: > > This commit adds device tree support for tps65217 pmic. And usage > > details are added to device tree documentation. Driver is tested > > by using kernel module with regulator set and get APIs. > > Applied, thanks. Thanks much, are you going to push reset of the patches in this series? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] fs/ufs: stop using write_supers and s_dirt
On Fri, 13 Jul 2012 08:34:44 +0300 Artem Bityutskiy wrote: > On Thu, 2012-07-12 at 15:58 -0700, Andrew Morton wrote: > > Just fix them up as you go - the code is already a mixture of "right" > > and "wrong" (a consequence of a lot of it being "wrong") - we might as > > well tip it further in the "right" direction. > > Yeah, but I'd say 80% of it has its own "wrong" coding style, so fixing > it is a separate patch-set. Simply because when I partially fix it, > there are almost always context lines which upset checkpatch.pl, so I > would need to fix it all. I can easily clean it up a bit separately, > just let me know if you want me to do this. checkpatch does not report on context lines - only on added lines. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] fs/ufs: stop using write_supers and s_dirt
On Thu, 2012-07-12 at 15:58 -0700, Andrew Morton wrote: > Just fix them up as you go - the code is already a mixture of "right" > and "wrong" (a consequence of a lot of it being "wrong") - we might as > well tip it further in the "right" direction. Yeah, but I'd say 80% of it has its own "wrong" coding style, so fixing it is a separate patch-set. Simply because when I partially fix it, there are almost always context lines which upset checkpatch.pl, so I would need to fix it all. I can easily clean it up a bit separately, just let me know if you want me to do this. Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [Xen-devel] [PATCH] xen: populate correct number of pages when across mem boundary
于 2012-07-12 22:55, David Vrabel 写道:
On 04/07/12 07:49, zhenzhong.duan wrote:
When populate pages across a mem boundary at bootup, the page count
populated isn't correct. This is due to mem populated to non-mem
region and ignored.
Pfn range is also wrongly aligned when mem boundary isn't page aligned.
Also need consider the rare case when xen_do_chunk fail(populate).
For a dom0 booted with dom_mem=3368952K(0xcd9ff000-4k) dmesg diff is:
[0.00] Freeing 9e-100 pfn range: 98 pages freed
[0.00] 1-1 mapping on 9e->100
[0.00] 1-1 mapping on cd9ff->10
[0.00] Released 98 pages of unused memory
[0.00] Set 206435 page(s) to 1-1 mapping
-[0.00] Populating cd9fe-cda00 pfn range: 1 pages added
+[0.00] Populating cd9fe-cd9ff pfn range: 1 pages added
+[0.00] Populating 10-100061 pfn range: 97 pages added
[0.00] BIOS-provided physical RAM map:
[0.00] Xen: - 0009e000 (usable)
[0.00] Xen: 000a - 0010 (reserved)
[0.00] Xen: 0010 - cd9ff000 (usable)
[0.00] Xen: cd9ffc00 - cda53c00 (ACPI NVS)
...
[0.00] Xen: 0001 - 000100061000 (usable)
[0.00] Xen: 000100061000 - 00012c00 (unusable)
...
[0.00] MEMBLOCK configuration:
...
-[0.00] reserved[0x4] [0x00cd9ff000-0x00cd9ffbff], 0xc00
bytes
-[0.00] reserved[0x5] [0x01-0x0100060fff],
0x61000 bytes
Related xen memory layout:
(XEN) Xen-e820 RAM map:
(XEN) - 0009ec00 (usable)
(XEN) 000f - 0010 (reserved)
(XEN) 0010 - cd9ffc00 (usable)
Signed-off-by: Zhenzhong Duan
---
arch/x86/xen/setup.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index a4790bf..bd78773 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -157,50 +157,48 @@ static unsigned long __init xen_populate_chunk(
unsigned long dest_pfn;
for (i = 0, entry = list; i< map_size; i++, entry++) {
- unsigned long credits = credits_left;
unsigned long s_pfn;
unsigned long e_pfn;
unsigned long pfns;
long capacity;
- if (credits<= 0)
+ if (credits_left<= 0)
break;
if (entry->type != E820_RAM)
continue;
- e_pfn = PFN_UP(entry->addr + entry->size);
+ e_pfn = PFN_DOWN(entry->addr + entry->size);
Ok.
/* We only care about E820 after the xen_start_info->nr_pages */
if (e_pfn<= max_pfn)
continue;
- s_pfn = PFN_DOWN(entry->addr);
+ s_pfn = PFN_UP(entry->addr);
Ok.
/* If the E820 falls within the nr_pages, we want to start
* at the nr_pages PFN.
* If that would mean going past the E820 entry, skip it
*/
+again:
if (s_pfn<= max_pfn) {
capacity = e_pfn - max_pfn;
dest_pfn = max_pfn;
} else {
- /* last_pfn MUST be within E820_RAM regions */
- if (*last_pfn&& e_pfn>= *last_pfn)
- s_pfn = *last_pfn;
capacity = e_pfn - s_pfn;
dest_pfn = s_pfn;
}
- /* If we had filled this E820_RAM entry, go to the next one. */
- if (capacity<= 0)
- continue;
- if (credits> capacity)
- credits = capacity;
+ if (credits_left< capacity)
+ capacity = credits_left;
- pfns = xen_do_chunk(dest_pfn, dest_pfn + credits, false);
+ pfns = xen_do_chunk(dest_pfn, dest_pfn + capacity, false);
done += pfns;
credits_left -= pfns;
*last_pfn = (dest_pfn + pfns);
+ if (credits_left> 0&& *last_pfn< e_pfn) {
+ s_pfn = *last_pfn;
+ goto again;
+ }
This looks like it will loop forever if xen_do_chunk() repeatedly fails
because Xen is out of pages. I think if xen_do_chunk() cannot get a
page from Xen the repopulation process should stop -- aborting this
chunk and any others. This will allow the guest to continue to boot
just with less memory than expected.
David
Ok, I'll update the patch, loop forever isn't a good idea.
Originally, I considered the case there is dynamic memory control
functionality in the system.
thanks for comment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
[PATCH net-next 8/8] arch: Use eth_random_addr
Convert the existing uses of random_ether_addr to
the new eth_random_addr.
Signed-off-by: Joe Perches
---
arch/blackfin/mach-bf537/boards/stamp.c |2 +-
arch/c6x/kernel/soc.c |2 +-
arch/mips/ar7/platform.c|4 ++--
arch/mips/powertv/powertv_setup.c |6 +++---
arch/um/drivers/net_kern.c |2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/blackfin/mach-bf537/boards/stamp.c
b/arch/blackfin/mach-bf537/boards/stamp.c
index c9d9473..5ed654a 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -873,7 +873,7 @@ static struct adf702x_platform_data adf7021_platform_data =
{
};
static inline void adf702x_mac_init(void)
{
- random_ether_addr(adf7021_platform_data.mac_addr);
+ eth_random_addr(adf7021_platform_data.mac_addr);
}
#else
static inline void adf702x_mac_init(void) {}
diff --git a/arch/c6x/kernel/soc.c b/arch/c6x/kernel/soc.c
index 0748c94..3ac7408 100644
--- a/arch/c6x/kernel/soc.c
+++ b/arch/c6x/kernel/soc.c
@@ -80,7 +80,7 @@ int soc_mac_addr(unsigned int index, u8 *addr)
if (have_fuse_mac)
memcpy(addr, c6x_fuse_mac, 6);
else
- random_ether_addr(addr);
+ eth_random_addr(addr);
}
/* adjust for specific EMAC device */
diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c
index 1a24d31..1bbc24b 100644
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -310,10 +310,10 @@ static void __init cpmac_get_mac(int instance, unsigned
char *dev_addr)
&dev_addr[4], &dev_addr[5]) != 6) {
pr_warning("cannot parse mac address, "
"using random address\n");
- random_ether_addr(dev_addr);
+ eth_random_addr(dev_addr);
}
} else
- random_ether_addr(dev_addr);
+ eth_random_addr(dev_addr);
}
/*
diff --git a/arch/mips/powertv/powertv_setup.c
b/arch/mips/powertv/powertv_setup.c
index 3933c37..820b848 100644
--- a/arch/mips/powertv/powertv_setup.c
+++ b/arch/mips/powertv/powertv_setup.c
@@ -254,7 +254,7 @@ early_param("rfmac", rfmac_param);
* Generates an Ethernet MAC address that is highly likely to be unique for
* this particular system on a network with other systems of the same type.
*
- * The problem we are solving is that, when random_ether_addr() is used to
+ * The problem we are solving is that, when eth_random_addr() is used to
* generate MAC addresses at startup, there isn't much entropy for the random
* number generator to use and the addresses it produces are fairly likely to
* be the same as those of other identical systems on the same local network.
@@ -269,7 +269,7 @@ early_param("rfmac", rfmac_param);
* Still, this does give us something to work with.
*
* The approach we take is:
- * 1. If we can't get the RF MAC Address, just call random_ether_addr.
+ * 1. If we can't get the RF MAC Address, just call eth_random_addr.
* 2. Use the 24-bit NIC-specific bits of the RF MAC address as the last 24
* bits of the new address. This is very likely to be unique, except for
* the current box.
@@ -299,7 +299,7 @@ void platform_random_ether_addr(u8 addr[ETH_ALEN])
if (!have_rfmac) {
pr_warning("rfmac not available on command line; "
"generating random MAC address\n");
- random_ether_addr(addr);
+ eth_random_addr(addr);
}
else {
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index 0d60c56..458d324 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -339,7 +339,7 @@ static int setup_etheraddr(char *str, unsigned char *addr,
char *name)
random:
printk(KERN_INFO
"Choosing a random ethernet address for device %s\n", name);
- random_ether_addr(addr);
+ eth_random_addr(addr);
return 1;
}
--
1.7.8.111.gad25c.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 7/8] usb: Use eth_random_addr
Convert the existing uses of random_ether_addr to the new eth_random_addr. Signed-off-by: Joe Perches --- drivers/usb/atm/xusbatm.c|4 ++-- drivers/usb/gadget/u_ether.c |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/atm/xusbatm.c b/drivers/usb/atm/xusbatm.c index 14ec9f0..b3b1bb7 100644 --- a/drivers/usb/atm/xusbatm.c +++ b/drivers/usb/atm/xusbatm.c @@ -20,7 +20,7 @@ **/ #include -#include /* for random_ether_addr() */ +#include /* for eth_random_addr() */ #include "usbatm.h" @@ -163,7 +163,7 @@ static int xusbatm_atm_start(struct usbatm_data *usbatm, atm_dbg(usbatm, "%s entered\n", __func__); /* use random MAC as we've no way to get it from the device */ - random_ether_addr(atm_dev->esi); + eth_random_addr(atm_dev->esi); return 0; } diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c index 47cf48b..b9e1925 100644 --- a/drivers/usb/gadget/u_ether.c +++ b/drivers/usb/gadget/u_ether.c @@ -724,7 +724,7 @@ static int get_ether_addr(const char *str, u8 *dev_addr) if (is_valid_ether_addr(dev_addr)) return 0; } - random_ether_addr(dev_addr); + eth_random_addr(dev_addr); return 1; } -- 1.7.8.111.gad25c.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 6/8] s390: Use eth_random_addr
Convert the existing uses of random_ether_addr to
the new eth_random_addr.
Signed-off-by: Joe Perches
---
drivers/s390/net/qeth_l2_main.c |2 +-
drivers/s390/net/qeth_l3_main.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/s390/net/qeth_l2_main.c b/drivers/s390/net/qeth_l2_main.c
index 4269865..b09355c 100644
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -647,7 +647,7 @@ static int qeth_l2_request_initial_mac(struct qeth_card
*card)
}
QETH_DBF_HEX(SETUP, 2, card->dev->dev_addr, OSA_ADDR_LEN);
} else {
- random_ether_addr(card->dev->dev_addr);
+ eth_random_addr(card->dev->dev_addr);
memcpy(card->dev->dev_addr, vendor_pre, 3);
}
return 0;
diff --git a/drivers/s390/net/qeth_l3_main.c b/drivers/s390/net/qeth_l3_main.c
index 73ac63d..bada7f6 100644
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -1473,7 +1473,7 @@ static int qeth_l3_iqd_read_initial_mac_cb(struct
qeth_card *card,
memcpy(card->dev->dev_addr,
cmd->data.create_destroy_addr.unique_id, ETH_ALEN);
else
- random_ether_addr(card->dev->dev_addr);
+ eth_random_addr(card->dev->dev_addr);
return 0;
}
--
1.7.8.111.gad25c.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 5/8] drivers/net: Use eth_random_addr
Convert the existing uses of random_ether_addr to the new eth_random_addr. Signed-off-by: Joe Perches --- drivers/net/tun.c |2 +- drivers/net/wimax/i2400m/driver.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 987aeef..961fad1 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -22,7 +22,7 @@ *Add TUNSETLINK ioctl to set the link encapsulation * * Mark Smith - *Use random_ether_addr() for tap MAC address. + *Use eth_random_addr() for tap MAC address. * * Harald Roelle 2004/04/20 *Fixes in packet dropping, queue length setting and queue wakeup. diff --git a/drivers/net/wimax/i2400m/driver.c b/drivers/net/wimax/i2400m/driver.c index 47cae71..01d400d 100644 --- a/drivers/net/wimax/i2400m/driver.c +++ b/drivers/net/wimax/i2400m/driver.c @@ -897,7 +897,7 @@ int i2400m_setup(struct i2400m *i2400m, enum i2400m_bri bm_flags) result = i2400m_read_mac_addr(i2400m); if (result < 0) goto error_read_mac_addr; - random_ether_addr(i2400m->src_mac_addr); + eth_random_addr(i2400m->src_mac_addr); i2400m->pm_notifier.notifier_call = i2400m_pm_notifier; register_pm_notifier(&i2400m->pm_notifier); -- 1.7.8.111.gad25c.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 4/8] wireless: Use eth_random_addr
Convert the existing uses of random_ether_addr to
the new eth_random_addr.
Signed-off-by: Joe Perches
---
drivers/net/wireless/adm8211.c |2 +-
drivers/net/wireless/p54/eeprom.c |2 +-
drivers/net/wireless/rt2x00/rt2400pci.c|2 +-
drivers/net/wireless/rt2x00/rt2500pci.c|2 +-
drivers/net/wireless/rt2x00/rt2500usb.c|2 +-
drivers/net/wireless/rt2x00/rt2800lib.c|2 +-
drivers/net/wireless/rt2x00/rt61pci.c |2 +-
drivers/net/wireless/rt2x00/rt73usb.c |2 +-
drivers/net/wireless/rtl818x/rtl8180/dev.c |2 +-
drivers/net/wireless/rtl818x/rtl8187/dev.c |2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index 97afcec..689a71c 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -1854,7 +1854,7 @@ static int __devinit adm8211_probe(struct pci_dev *pdev,
if (!is_valid_ether_addr(perm_addr)) {
printk(KERN_WARNING "%s (adm8211): Invalid hwaddr in EEPROM!\n",
pci_name(pdev));
- random_ether_addr(perm_addr);
+ eth_random_addr(perm_addr);
}
SET_IEEE80211_PERM_ADDR(dev, perm_addr);
diff --git a/drivers/net/wireless/p54/eeprom.c
b/drivers/net/wireless/p54/eeprom.c
index 636daf2..1403709 100644
--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -857,7 +857,7 @@ good_eeprom:
wiphy_warn(dev->wiphy,
"Invalid hwaddr! Using randomly generated MAC
addr\n");
- random_ether_addr(perm_addr);
+ eth_random_addr(perm_addr);
SET_IEEE80211_PERM_ADDR(dev, perm_addr);
}
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c
b/drivers/net/wireless/rt2x00/rt2400pci.c
index 5e6b501..8b9dbd7 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1455,7 +1455,7 @@ static int rt2400pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
if (!is_valid_ether_addr(mac)) {
- random_ether_addr(mac);
+ eth_random_addr(mac);
EEPROM(rt2x00dev, "MAC: %pM\n", mac);
}
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c
b/drivers/net/wireless/rt2x00/rt2500pci.c
index 136b849..d2cf8a4 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1585,7 +1585,7 @@ static int rt2500pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
if (!is_valid_ether_addr(mac)) {
- random_ether_addr(mac);
+ eth_random_addr(mac);
EEPROM(rt2x00dev, "MAC: %pM\n", mac);
}
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c
b/drivers/net/wireless/rt2x00/rt2500usb.c
index 669aecd..3aae36b 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1352,7 +1352,7 @@ static int rt2500usb_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
if (!is_valid_ether_addr(mac)) {
- random_ether_addr(mac);
+ eth_random_addr(mac);
EEPROM(rt2x00dev, "MAC: %pM\n", mac);
}
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index 068276e..d857d55 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -4340,7 +4340,7 @@ int rt2800_validate_eeprom(struct rt2x00_dev *rt2x00dev)
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
if (!is_valid_ether_addr(mac)) {
- random_ether_addr(mac);
+ eth_random_addr(mac);
EEPROM(rt2x00dev, "MAC: %pM\n", mac);
}
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c
b/drivers/net/wireless/rt2x00/rt61pci.c
index ee22bd7..f322596 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2415,7 +2415,7 @@ static int rt61pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
if (!is_valid_ether_addr(mac)) {
- random_ether_addr(mac);
+ eth_random_addr(mac);
EEPROM(rt2x00dev, "MAC: %pM\n", mac);
}
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c
b/drivers/net/wireless/rt2x00/rt73usb.c
index 77ccbbc..ba6e434 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -1770,7 +1770,7 @@ static int rt73usb_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
i
[PATCH net-next 3/8] net: usb: Use eth_random_addr
Convert the existing uses of random_ether_addr to the new eth_random_addr. Signed-off-by: Joe Perches --- drivers/net/usb/smsc75xx.c |2 +- drivers/net/usb/smsc95xx.c |2 +- drivers/net/usb/usbnet.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c index 1c6e515..6c0c5b7 100644 --- a/drivers/net/usb/smsc75xx.c +++ b/drivers/net/usb/smsc75xx.c @@ -616,7 +616,7 @@ static void smsc75xx_init_mac_address(struct usbnet *dev) /* no eeprom, or eeprom values are invalid. generate random MAC */ eth_hw_addr_random(dev->net); - netif_dbg(dev, ifup, dev->net, "MAC address set to random_ether_addr"); + netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr"); } static int smsc75xx_set_mac_address(struct usbnet *dev) diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c index bd7cbaa..25cc3a1 100644 --- a/drivers/net/usb/smsc95xx.c +++ b/drivers/net/usb/smsc95xx.c @@ -647,7 +647,7 @@ static void smsc95xx_init_mac_address(struct usbnet *dev) /* no eeprom, or eeprom values are invalid. generate random MAC */ eth_hw_addr_random(dev->net); - netif_dbg(dev, ifup, dev->net, "MAC address set to random_ether_addr\n"); + netif_dbg(dev, ifup, dev->net, "MAC address set to eth_random_addr\n"); } static int smsc95xx_set_mac_address(struct usbnet *dev) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index e92c057..8531c1c 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -1593,7 +1593,7 @@ static int __init usbnet_init(void) BUILD_BUG_ON( FIELD_SIZEOF(struct sk_buff, cb) < sizeof(struct skb_data)); - random_ether_addr(node_id); + eth_random_addr(node_id); return 0; } module_init(usbnet_init); -- 1.7.8.111.gad25c.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/8] ethernet: Use eth_random_addr
Convert the existing uses of random_ether_addr to
the new eth_random_addr.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/atheros/atl1c/atl1c_hw.c |2 +-
drivers/net/ethernet/atheros/atlx/atl1.c |2 +-
drivers/net/ethernet/atheros/atlx/atl2.c |2 +-
drivers/net/ethernet/ethoc.c |2 +-
drivers/net/ethernet/intel/igb/igb_main.c |4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c|2 +-
drivers/net/ethernet/lantiq_etop.c|2 +-
drivers/net/ethernet/micrel/ks8851.c |2 +-
drivers/net/ethernet/micrel/ks8851_mll.c |2 +-
drivers/net/ethernet/smsc/smsc911x.c |2 +-
drivers/net/ethernet/ti/cpsw.c|2 +-
drivers/net/ethernet/tile/tilegx.c|2 +-
drivers/net/ethernet/wiznet/w5100.c |2 +-
drivers/net/ethernet/wiznet/w5300.c |2 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c |2 +-
15 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_hw.c
b/drivers/net/ethernet/atheros/atl1c/atl1c_hw.c
index 801f012..21e261f 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_hw.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_hw.c
@@ -199,7 +199,7 @@ int atl1c_read_mac_addr(struct atl1c_hw *hw)
err = atl1c_get_permanent_address(hw);
if (err)
- random_ether_addr(hw->perm_mac_addr);
+ eth_random_addr(hw->perm_mac_addr);
memcpy(hw->mac_addr, hw->perm_mac_addr, sizeof(hw->perm_mac_addr));
return err;
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c
b/drivers/net/ethernet/atheros/atlx/atl1.c
index f2402f3..7bae2ad 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -538,7 +538,7 @@ static s32 atl1_read_mac_addr(struct atl1_hw *hw)
u16 i;
if (atl1_get_permanent_address(hw)) {
- random_ether_addr(hw->perm_mac_addr);
+ eth_random_addr(hw->perm_mac_addr);
ret = 1;
}
diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c
b/drivers/net/ethernet/atheros/atlx/atl2.c
index 7c0b7e2..57d64b8 100644
--- a/drivers/net/ethernet/atheros/atlx/atl2.c
+++ b/drivers/net/ethernet/atheros/atlx/atl2.c
@@ -2346,7 +2346,7 @@ static s32 atl2_read_mac_addr(struct atl2_hw *hw)
{
if (get_permanent_address(hw)) {
/* for test */
- /* FIXME: shouldn't we use random_ether_addr() here? */
+ /* FIXME: shouldn't we use eth_random_addr() here? */
hw->perm_mac_addr[0] = 0x00;
hw->perm_mac_addr[1] = 0x13;
hw->perm_mac_addr[2] = 0x74;
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 2029788..94b7bfc 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -1057,7 +1057,7 @@ static int __devinit ethoc_probe(struct platform_device
*pdev)
/* Check the MAC again for validity, if it still isn't choose and
* program a random one. */
if (!is_valid_ether_addr(netdev->dev_addr)) {
- random_ether_addr(netdev->dev_addr);
+ eth_random_addr(netdev->dev_addr);
random_mac = true;
}
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 60e3075..8adeca9 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5008,7 +5008,7 @@ static int igb_vf_configure(struct igb_adapter *adapter,
int vf)
unsigned int device_id;
u16 thisvf_devfn;
- random_ether_addr(mac_addr);
+ eth_random_addr(mac_addr);
igb_set_vf_mac(adapter, vf, mac_addr);
switch (adapter->hw.mac.type) {
@@ -5417,7 +5417,7 @@ static void igb_vf_reset_event(struct igb_adapter
*adapter, u32 vf)
/* generate a new mac address as we were hotplug removed/added */
if (!(adapter->vf_data[vf].flags & IGB_VF_FLAG_PF_SET_MAC))
- random_ether_addr(vf_mac);
+ eth_random_addr(vf_mac);
/* process remaining reset events */
igb_vf_reset(adapter, vf);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 2d971d1..eb3f67c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -467,7 +467,7 @@ int ixgbe_vf_configuration(struct pci_dev *pdev, unsigned
int event_mask)
bool enable = ((event_mask & 0x1000U) != 0);
if (enable) {
- random_ether_addr(vf_mac_addr);
+ eth_random_addr(vf_mac_addr);
e_info(probe, "IOV: VF %d is enabled MAC %pM\n",
vfn, vf_mac_addr);
/*
diff --git a/drivers/net/ethernet/lantiq_etop.c
[PATCH net-next 1/8] etherdevice: Rename random_ether_addr to eth_random_addr
Add some API symmetry to eth_broadcast_addr and
add a #define to the old name for backward compatibility.
Signed-off-by: Joe Perches
---
include/linux/etherdevice.h | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 98a27cc..d426336 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -124,19 +124,21 @@ static inline bool is_valid_ether_addr(const u8 *addr)
}
/**
- * random_ether_addr - Generate software assigned random Ethernet address
+ * eth_random_addr - Generate software assigned random Ethernet address
* @addr: Pointer to a six-byte array containing the Ethernet address
*
* Generate a random Ethernet address (MAC) that is not multicast
* and has the local assigned bit set.
*/
-static inline void random_ether_addr(u8 *addr)
+static inline void eth_random_addr(u8 *addr)
{
- get_random_bytes (addr, ETH_ALEN);
- addr [0] &= 0xfe; /* clear multicast bit */
- addr [0] |= 0x02; /* set local assignment bit (IEEE802) */
+ get_random_bytes(addr, ETH_ALEN);
+ addr[0] &= 0xfe;/* clear multicast bit */
+ addr[0] |= 0x02;/* set local assignment bit (IEEE802) */
}
+#define random_ether_addr(addr) eth_random_addr(addr)
+
/**
* eth_broadcast_addr - Assign broadcast address
* @addr: Pointer to a six-byte array containing the Ethernet address
@@ -160,7 +162,7 @@ static inline void eth_broadcast_addr(u8 *addr)
static inline void eth_hw_addr_random(struct net_device *dev)
{
dev->addr_assign_type |= NET_ADDR_RANDOM;
- random_ether_addr(dev->dev_addr);
+ eth_random_addr(dev->dev_addr);
}
/**
--
1.7.8.111.gad25c.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
net-next commit ad7eee98be ("etherdevice: introduce eth_broadcast_addr")
added a new style API. Rename random_ether_addr to eth_random_addr to
create some API symmetry.
Joe Perches (8):
etherdevice: Rename random_ether_addr to eth_random_addr
ethernet: Use eth_random_addr
net: usb: Use eth_random_addr
wireless: Use eth_random_addr
drivers/net: Use eth_random_addr
s390: Use eth_random_addr
usb: Use eth_random_addr
arch: Use eth_random_addr
arch/blackfin/mach-bf537/boards/stamp.c |2 +-
arch/c6x/kernel/soc.c |2 +-
arch/mips/ar7/platform.c |4 ++--
arch/mips/powertv/powertv_setup.c |6 +++---
arch/um/drivers/net_kern.c|2 +-
drivers/net/ethernet/atheros/atl1c/atl1c_hw.c |2 +-
drivers/net/ethernet/atheros/atlx/atl1.c |2 +-
drivers/net/ethernet/atheros/atlx/atl2.c |2 +-
drivers/net/ethernet/ethoc.c |2 +-
drivers/net/ethernet/intel/igb/igb_main.c |4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c|2 +-
drivers/net/ethernet/lantiq_etop.c|2 +-
drivers/net/ethernet/micrel/ks8851.c |2 +-
drivers/net/ethernet/micrel/ks8851_mll.c |2 +-
drivers/net/ethernet/smsc/smsc911x.c |2 +-
drivers/net/ethernet/ti/cpsw.c|2 +-
drivers/net/ethernet/tile/tilegx.c|2 +-
drivers/net/ethernet/wiznet/w5100.c |2 +-
drivers/net/ethernet/wiznet/w5300.c |2 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c |2 +-
drivers/net/tun.c |2 +-
drivers/net/usb/smsc75xx.c|2 +-
drivers/net/usb/smsc95xx.c|2 +-
drivers/net/usb/usbnet.c |2 +-
drivers/net/wimax/i2400m/driver.c |2 +-
drivers/net/wireless/adm8211.c|2 +-
drivers/net/wireless/p54/eeprom.c |2 +-
drivers/net/wireless/rt2x00/rt2400pci.c |2 +-
drivers/net/wireless/rt2x00/rt2500pci.c |2 +-
drivers/net/wireless/rt2x00/rt2500usb.c |2 +-
drivers/net/wireless/rt2x00/rt2800lib.c |2 +-
drivers/net/wireless/rt2x00/rt61pci.c |2 +-
drivers/net/wireless/rt2x00/rt73usb.c |2 +-
drivers/net/wireless/rtl818x/rtl8180/dev.c|2 +-
drivers/net/wireless/rtl818x/rtl8187/dev.c|2 +-
drivers/s390/net/qeth_l2_main.c |2 +-
drivers/s390/net/qeth_l3_main.c |2 +-
drivers/usb/atm/xusbatm.c |4 ++--
drivers/usb/gadget/u_ether.c |2 +-
include/linux/etherdevice.h | 14 --
40 files changed, 52 insertions(+), 50 deletions(-)
--
1.7.8.111.gad25c.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH V2 3/3] tegra: add pwm backlight device tree nodes
On 07/12/2012 11:27 PM, Simon Glass wrote
I agree the type strings are a problem in the current form - if we could get
constants in the device tree, that would be much better. Your way of
representing the sequences is interesting though, if we can solve the type
issue (and also evaluate its cost in terms of memory footprint), it would be
interesting to consider it as well.
At a guess:
+ power-on-sequence = "REGULATOR", "power", <1>,
+ "DELAY", <10>,
+ "PWM", "backlight", <1>,
+ "GPIO", "enable", <1>;
About 106 bytes I think
step@0 { 16
type = "regulator"; 24
phandle = <&backlight_reg>; 16
enable = <1>; 16
post-delay = <10>; 16
}
step@1 { 16
type = "pwm"; 16
phandle = <&pwm 2 500>; 24
}
step@2 { 16
type = "gpio"; 20
phandle = <&gpio 28 0>; 24
enable = <1>; 16
}
220?
I compiled both versions to try it out. Your version was just 50 bytes
larger than mine (I assumed that with yours, we would be able to remove
the top-level pwm/regulator/gpio definitions that are referred by the
sequence). The question here is do we want to have something more
DT-ish, or are we trying to save every possible byte in the DT structure?
As Thierry also mentionned, we are trying to provide the same feature
using the platform interface. I am not sure how we can elegantly support
both ways through this.
From my understanding mixing strings and numbers in a property is
frowned on though.
But doesn't it make sense in the current case? The power sequence is
basically a program that is run by an interpreter. From this
perspective, it makes more sense to me to have it as a binary field
rather than a hierarchy of nodes and properties that will be harder to
parse and will make error detection more complicated. I don't really see
any practical benefit from turning the steps into sub-nodes, but then
again I am not so familiar with the DT.
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] time: Move xtime_nsec adjustment underflow handling timekeeping_adjust
When we make adjustments speeding up the clock, its possible
for xtime_nsec to underflow. We already handle this properly,
but we do so from update_wall_time() instead of the more logical
timekeeping_adjust(), where the possible underflow actually
occurs.
Thus, move the correction logic to the timekeeping_adjust, which
is the function that causes the issue. Making update_wall_time()
more readable.
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Cochran
CC: Prarit Bhargava
CC: Thomas Gleixner
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index dd119355..4b76432 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -987,6 +987,27 @@ static void timekeeping_adjust(s64 offset)
timekeeper.xtime_nsec -= offset;
timekeeper.ntp_error -= (interval - offset) <<
timekeeper.ntp_error_shift;
+
+ /*
+* It may be possible that when we entered this function, xtime_nsec
+* was very small. Further, if we're slightly speeding the clocksource
+* in the code above, its possible the required corrective factor to
+* xtime_nsec could cause it to underflow.
+*
+* Now, since we already accumulated the second, cannot simply roll
+* the accumulated second back, since the NTP subsystem has been
+* notified via second_overflow. So instead we push xtime_nsec forward
+* by the amount we underflowed, and add that amount into the error.
+*
+* We'll correct this error next time through this function, when
+* xtime_nsec is not as small.
+*/
+ if (unlikely((s64)timekeeper.xtime_nsec < 0)) {
+ s64 neg = -(s64)timekeeper.xtime_nsec;
+ timekeeper.xtime_nsec = 0;
+ timekeeper.ntp_error += neg << timekeeper.ntp_error_shift;
+ }
+
}
@@ -1112,27 +1133,6 @@ static void update_wall_time(void)
/* correct the clock when NTP error is too big */
timekeeping_adjust(offset);
- /*
-* Since in the loop above, we accumulate any amount of time
-* in xtime_nsec over a second into xtime.tv_sec, its possible for
-* xtime_nsec to be fairly small after the loop. Further, if we're
-* slightly speeding the clocksource up in timekeeping_adjust(),
-* its possible the required corrective factor to xtime_nsec could
-* cause it to underflow.
-*
-* Now, we cannot simply roll the accumulated second back, since
-* the NTP subsystem has been notified via second_overflow. So
-* instead we push xtime_nsec forward by the amount we underflowed,
-* and add that amount into the error.
-*
-* We'll correct this error next time through this function, when
-* xtime_nsec is not as small.
-*/
- if (unlikely((s64)timekeeper.xtime_nsec < 0)) {
- s64 neg = -(s64)timekeeper.xtime_nsec;
- timekeeper.xtime_nsec = 0;
- timekeeper.ntp_error += neg << timekeeper.ntp_error_shift;
- }
/*
* Store only full nanoseconds into xtime_nsec after rounding
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] time: Condense timekeeper.xtime into xtime_sec
The timekeeper struct has a xtime_nsec, which keeps the
sub-nanosecond remainder. This ends up being somewhat
duplicative of the timekeeper.xtime.tv_nsec value, and we
have to do extra work to keep them apart, copying the full
nsec portion out and back in over and over.
This patch simplifies some of the logic by taking the timekeeper
xtime value and splitting it into timekeeper.xtime_sec and
reuses the timekeeper.xtime_nsec for the sub-second portion
(stored in higher res shifted nanoseconds).
This simplifies some of the accumulation logic. And will
allow for more accurate timekeeping once the vsyscall code
is updated to use the shifted nanosecond remainder.
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Cochran
CC: Prarit Bhargava
CC: Thomas Gleixner
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 183 -
1 file changed, 113 insertions(+), 70 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4fd83df..80d0c78 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -38,8 +38,11 @@ struct timekeeper {
/* Raw nano seconds accumulated per NTP interval. */
u32 raw_interval;
- /* Clock shifted nano seconds remainder not stored in xtime.tv_nsec. */
+ /* Current CLOCK_REALTIME time in seconds */
+ u64 xtime_sec;
+ /* Clock shifted nano seconds */
u64 xtime_nsec;
+
/* Difference between accumulated time and NTP time in ntp
* shifted nano seconds. */
s64 ntp_error;
@@ -47,8 +50,6 @@ struct timekeeper {
* ntp shifted nano seconds. */
u32 ntp_error_shift;
- /* The current time */
- struct timespec xtime;
/*
* wall_to_monotonic is what we need to add to xtime (or xtime corrected
* for sub jiffie times) to get to monotonic time. Monotonic is pegged
@@ -89,6 +90,36 @@ __cacheline_aligned_in_smp DEFINE_SEQLOCK(xtime_lock);
int __read_mostly timekeeping_suspended;
+static inline void tk_normalize_xtime(struct timekeeper *tk)
+{
+ while (tk->xtime_nsec >= ((u64)NSEC_PER_SEC << tk->shift)) {
+ tk->xtime_nsec -= (u64)NSEC_PER_SEC << tk->shift;
+ tk->xtime_sec++;
+ }
+}
+
+static struct timespec tk_xtime(struct timekeeper *tk)
+{
+ struct timespec ts;
+
+ ts.tv_sec = tk->xtime_sec;
+ ts.tv_nsec = (long)(tk->xtime_nsec >> tk->shift);
+ return ts;
+}
+
+static void tk_set_xtime(struct timekeeper *tk, const struct timespec *ts)
+{
+ tk->xtime_sec = ts->tv_sec;
+ tk->xtime_nsec = ts->tv_nsec << tk->shift;
+}
+
+
+static void tk_xtime_add(struct timekeeper *tk, const struct timespec *ts)
+{
+ tk->xtime_sec += ts->tv_sec;
+ tk->xtime_nsec += ts->tv_nsec << tk->shift;
+}
+
/**
* timekeeper_setup_internals - Set up internals to use clocksource clock.
@@ -104,7 +135,9 @@ static void timekeeper_setup_internals(struct clocksource
*clock)
{
cycle_t interval;
u64 tmp, ntpinterval;
+ struct clocksource *old_clock;
+ old_clock = timekeeper.clock;
timekeeper.clock = clock;
clock->cycle_last = clock->read(clock);
@@ -126,7 +159,14 @@ static void timekeeper_setup_internals(struct clocksource
*clock)
timekeeper.raw_interval =
((u64) interval * clock->mult) >> clock->shift;
- timekeeper.xtime_nsec = 0;
+/* if changing clocks, convert xtime_nsec shift units */
+ if (old_clock) {
+ int shift_change = clock->shift - old_clock->shift;
+ if (shift_change < 0)
+ timekeeper.xtime_nsec >>= -shift_change;
+ else
+ timekeeper.xtime_nsec <<= shift_change;
+ }
timekeeper.shift = clock->shift;
timekeeper.ntp_error = 0;
@@ -145,6 +185,7 @@ static inline s64 timekeeping_get_ns(void)
{
cycle_t cycle_now, cycle_delta;
struct clocksource *clock;
+ s64 nsec;
/* read clocksource: */
clock = timekeeper.clock;
@@ -153,9 +194,8 @@ static inline s64 timekeeping_get_ns(void)
/* calculate the delta since the last update_wall_time: */
cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
- /* return delta convert to nanoseconds using ntp adjusted mult. */
- return clocksource_cyc2ns(cycle_delta, timekeeper.mult,
- timekeeper.shift);
+ nsec = cycle_delta * timekeeper.mult + timekeeper.xtime_nsec;
+ return nsec >> timekeeper.shift;
}
static inline s64 timekeeping_get_ns_raw(void)
@@ -185,12 +225,15 @@ static void update_rt_offset(void)
/* must hold write on timekeeper.lock */
static void timekeeping_update(bool clearntp)
{
+ struct timespec xt;
+
if (clearntp) {
ti
[PATCH 5/8] time: Refactor accumulation of nsecs to secs
We do the exact same logic moving nsecs to secs in the
timekeeper in multiple places, so condense this into a
single function.
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Cochran
CC: Prarit Bhargava
CC: Thomas Gleixner
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 54 +++--
1 file changed, 32 insertions(+), 22 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 80d0c78..5ffb2b6 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -995,6 +995,35 @@ static void timekeeping_adjust(s64 offset)
/**
+ * accumulate_nsecs_to_secs - Accumulates nsecs into secs
+ *
+ * Helper function that accumulates a the nsecs greater then a second
+ * from the xtime_nsec field to the xtime_secs field.
+ * It also calls into the NTP code to handle leapsecond processing.
+ *
+ */
+static inline void accumulate_nsecs_to_secs(struct timekeeper *tk)
+{
+ u64 nsecps = (u64)NSEC_PER_SEC << tk->shift;
+
+ while (tk->xtime_nsec >= nsecps) {
+ int leap;
+
+ tk->xtime_nsec -= nsecps;
+ tk->xtime_sec++;
+
+ /* Figure out if its a leap sec and apply if needed */
+ leap = second_overflow(tk->xtime_sec);
+ tk->xtime_sec += leap;
+ tk->wall_to_monotonic.tv_sec -= leap;
+ if (leap)
+ clock_was_set_delayed();
+
+ }
+}
+
+
+/**
* logarithmic_accumulation - shifted accumulation of cycles
*
* This functions accumulates a shifted interval of cycles into
@@ -1005,7 +1034,6 @@ static void timekeeping_adjust(s64 offset)
*/
static cycle_t logarithmic_accumulation(cycle_t offset, u32 shift)
{
- u64 nsecps = (u64)NSEC_PER_SEC << timekeeper.shift;
u64 raw_nsecs;
/* If the offset is smaller than a shifted interval, do nothing */
@@ -1017,16 +1045,8 @@ static cycle_t logarithmic_accumulation(cycle_t offset,
u32 shift)
timekeeper.clock->cycle_last += timekeeper.cycle_interval << shift;
timekeeper.xtime_nsec += timekeeper.xtime_interval << shift;
- while (timekeeper.xtime_nsec >= nsecps) {
- int leap;
- timekeeper.xtime_nsec -= nsecps;
- timekeeper.xtime_sec++;
- leap = second_overflow(timekeeper.xtime_sec);
- timekeeper.xtime_sec += leap;
- timekeeper.wall_to_monotonic.tv_sec -= leap;
- if (leap)
- clock_was_set_delayed();
- }
+
+ accumulate_nsecs_to_secs(&timekeeper);
/* Accumulate raw time */
raw_nsecs = timekeeper.raw_interval << shift;
@@ -1136,17 +1156,7 @@ static void update_wall_time(void)
* Finally, make sure that after the rounding
* xtime_nsec isn't larger than NSEC_PER_SEC
*/
- if (unlikely(timekeeper.xtime_nsec >=
- ((u64)NSEC_PER_SEC << timekeeper.shift))) {
- int leap;
- timekeeper.xtime_nsec -= (u64)NSEC_PER_SEC << timekeeper.shift;
- timekeeper.xtime_sec++;
- leap = second_overflow(timekeeper.xtime_sec);
- timekeeper.xtime_sec += leap;
- timekeeper.wall_to_monotonic.tv_sec -= leap;
- if (leap)
- clock_was_set_delayed();
- }
+ accumulate_nsecs_to_secs(&timekeeper);
timekeeping_update(false);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] time: Move arch_gettimeoffset() usage into timekeeping_get_ns()
Since we call arch_gettimeoffset() in all the accessor
functions, move arch_gettimeoffset() calls into
timekeeping_get_ns() and timekeeping_get_ns_raw() to simplify
the code.
This also makes the code easier to maintain as we don't have to
worry about forgetting the arch_gettimeoffset() as has happened
in the past.
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Cochran
CC: Prarit Bhargava
CC: Thomas Gleixner
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 5ffb2b6..dd119355 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -195,13 +195,18 @@ static inline s64 timekeeping_get_ns(void)
cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
nsec = cycle_delta * timekeeper.mult + timekeeper.xtime_nsec;
- return nsec >> timekeeper.shift;
+ nsec >>= timekeeper.shift;
+
+ /* If arch requires, add in gettimeoffset() */
+ nsec += arch_gettimeoffset();
+ return nsec;
}
static inline s64 timekeeping_get_ns_raw(void)
{
cycle_t cycle_now, cycle_delta;
struct clocksource *clock;
+ s64 nsec;
/* read clocksource: */
clock = timekeeper.clock;
@@ -210,8 +215,13 @@ static inline s64 timekeeping_get_ns_raw(void)
/* calculate the delta since the last update_wall_time: */
cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
- /* return delta convert to nanoseconds. */
- return clocksource_cyc2ns(cycle_delta, clock->mult, clock->shift);
+ /* convert delta to nanoseconds. */
+ nsec = clocksource_cyc2ns(cycle_delta, clock->mult, clock->shift);
+
+ /* If arch requires, add in gettimeoffset() */
+ nsec += arch_gettimeoffset();
+ return nsec;
+
}
static void update_rt_offset(void)
@@ -286,9 +296,6 @@ void getnstimeofday(struct timespec *ts)
ts->tv_sec = timekeeper.xtime_sec;
ts->tv_nsec = timekeeping_get_ns();
- /* If arch requires, add in gettimeoffset() */
- nsecs += arch_gettimeoffset();
-
} while (read_seqretry(&timekeeper.lock, seq));
timespec_add_ns(ts, nsecs);
@@ -308,8 +315,6 @@ ktime_t ktime_get(void)
timekeeper.wall_to_monotonic.tv_sec;
nsecs = timekeeping_get_ns() +
timekeeper.wall_to_monotonic.tv_nsec;
- /* If arch requires, add in gettimeoffset() */
- nsecs += arch_gettimeoffset();
} while (read_seqretry(&timekeeper.lock, seq));
/*
@@ -340,8 +345,6 @@ void ktime_get_ts(struct timespec *ts)
ts->tv_sec = timekeeper.xtime_sec;
ts->tv_nsec = timekeeping_get_ns();
tomono = timekeeper.wall_to_monotonic;
- /* If arch requires, add in gettimeoffset() */
- ts->tv_nsec += arch_gettimeoffset();
} while (read_seqretry(&timekeeper.lock, seq));
@@ -369,8 +372,6 @@ void getnstime_raw_and_real(struct timespec *ts_raw, struct
timespec *ts_real)
WARN_ON_ONCE(timekeeping_suspended);
do {
- u32 arch_offset;
-
seq = read_seqbegin(&timekeeper.lock);
*ts_raw = timekeeper.raw_time;
@@ -380,11 +381,6 @@ void getnstime_raw_and_real(struct timespec *ts_raw,
struct timespec *ts_real)
nsecs_raw = timekeeping_get_ns_raw();
nsecs_real = timekeeping_get_ns();
- /* If arch requires, add in gettimeoffset() */
- arch_offset = arch_gettimeoffset();
- nsecs_raw += arch_offset;
- nsecs_real += arch_offset;
-
} while (read_seqretry(&timekeeper.lock, seq));
timespec_add_ns(ts_raw, nsecs_raw);
@@ -1342,8 +1338,6 @@ ktime_t ktime_get_update_offsets(ktime_t *offs_real,
ktime_t *offs_boot)
secs = timekeeper.xtime_sec;
nsecs = timekeeping_get_ns();
- /* If arch requires, add in gettimeoffset() */
- nsecs += arch_gettimeoffset();
*offs_real = timekeeper.offs_real;
*offs_boot = timekeeper.offs_boot;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] time: Rework timekeeping functions to take timekeeper ptr as argument
As part of cleaning up the timekeeping code, this patch converts
a number of internal functions to takei a timekeeper ptr as an
argument, so that the internal functions don't access the global
timekeeper structure directly. This allows for further optimizations
to reduce lock hold time later.
This patch has been updated to include more consistent usage of the
timekeeper value, by making sure it is always passed as a argument
to non top-level functions.
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Cochran
CC: Prarit Bhargava
CC: Thomas Gleixner
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 210 ++---
1 file changed, 104 insertions(+), 106 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4b76432..7f08972 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -122,7 +122,7 @@ static void tk_xtime_add(struct timekeeper *tk, const
struct timespec *ts)
/**
- * timekeeper_setup_internals - Set up internals to use clocksource clock.
+ * tk_setup_internals - Set up internals to use clocksource clock.
*
* @clock: Pointer to clocksource.
*
@@ -131,14 +131,14 @@ static void tk_xtime_add(struct timekeeper *tk, const
struct timespec *ts)
*
* Unless you're the timekeeping code, you should not be using this!
*/
-static void timekeeper_setup_internals(struct clocksource *clock)
+static void tk_setup_internals(struct timekeeper *tk, struct clocksource
*clock)
{
cycle_t interval;
u64 tmp, ntpinterval;
struct clocksource *old_clock;
- old_clock = timekeeper.clock;
- timekeeper.clock = clock;
+ old_clock = tk->clock;
+ tk->clock = clock;
clock->cycle_last = clock->read(clock);
/* Do the ns -> cycle conversion first, using original mult */
@@ -151,65 +151,65 @@ static void timekeeper_setup_internals(struct clocksource
*clock)
tmp = 1;
interval = (cycle_t) tmp;
- timekeeper.cycle_interval = interval;
+ tk->cycle_interval = interval;
/* Go back from cycles -> shifted ns */
- timekeeper.xtime_interval = (u64) interval * clock->mult;
- timekeeper.xtime_remainder = ntpinterval - timekeeper.xtime_interval;
- timekeeper.raw_interval =
+ tk->xtime_interval = (u64) interval * clock->mult;
+ tk->xtime_remainder = ntpinterval - tk->xtime_interval;
+ tk->raw_interval =
((u64) interval * clock->mult) >> clock->shift;
/* if changing clocks, convert xtime_nsec shift units */
if (old_clock) {
int shift_change = clock->shift - old_clock->shift;
if (shift_change < 0)
- timekeeper.xtime_nsec >>= -shift_change;
+ tk->xtime_nsec >>= -shift_change;
else
- timekeeper.xtime_nsec <<= shift_change;
+ tk->xtime_nsec <<= shift_change;
}
- timekeeper.shift = clock->shift;
+ tk->shift = clock->shift;
- timekeeper.ntp_error = 0;
- timekeeper.ntp_error_shift = NTP_SCALE_SHIFT - clock->shift;
+ tk->ntp_error = 0;
+ tk->ntp_error_shift = NTP_SCALE_SHIFT - clock->shift;
/*
* The timekeeper keeps its own mult values for the currently
* active clocksource. These value will be adjusted via NTP
* to counteract clock drifting.
*/
- timekeeper.mult = clock->mult;
+ tk->mult = clock->mult;
}
/* Timekeeper helper functions. */
-static inline s64 timekeeping_get_ns(void)
+static inline s64 timekeeping_get_ns(struct timekeeper *tk)
{
cycle_t cycle_now, cycle_delta;
struct clocksource *clock;
s64 nsec;
/* read clocksource: */
- clock = timekeeper.clock;
+ clock = tk->clock;
cycle_now = clock->read(clock);
/* calculate the delta since the last update_wall_time: */
cycle_delta = (cycle_now - clock->cycle_last) & clock->mask;
- nsec = cycle_delta * timekeeper.mult + timekeeper.xtime_nsec;
- nsec >>= timekeeper.shift;
+ nsec = cycle_delta * tk->mult + tk->xtime_nsec;
+ nsec >>= tk->shift;
/* If arch requires, add in gettimeoffset() */
nsec += arch_gettimeoffset();
return nsec;
}
-static inline s64 timekeeping_get_ns_raw(void)
+static inline s64 timekeeping_get_ns_raw(struct timekeeper *tk)
{
cycle_t cycle_now, cycle_delta;
struct clocksource *clock;
s64 nsec;
/* read clocksource: */
- clock = timekeeper.clock;
+ clock = tk->clock;
cycle_now = clock->read(clock);
/* calculate the delta since the last update_wall_time: */
@@ -224,27 +224,26 @@ static inline s64 timekeeping_get_ns_raw(void)
}
-static void update_rt_offset(void)
+static void update_rt_offset(struct timekeeper *tk)
{
- struct timespec tmp
[PATCH 2/8] time: Whitespace cleanups per Ingo's requests
Ingo noted a number of places where there is inconsistent
use of whitespace. This patch tries to address the main
culprits.
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Cochran
CC: Prarit Bhargava
CC: Thomas Gleixner
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 39 ++-
1 file changed, 18 insertions(+), 21 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 269b1fe..c2f12aa 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -24,32 +24,31 @@
/* Structure holding internal timekeeping values. */
struct timekeeper {
/* Current clocksource used for timekeeping. */
- struct clocksource *clock;
+ struct clocksource *clock;
/* NTP adjusted clock multiplier */
- u32 mult;
+ u32 mult;
/* The shift value of the current clocksource. */
- int shift;
-
+ int shift;
/* Number of clock cycles in one NTP interval. */
- cycle_t cycle_interval;
+ cycle_t cycle_interval;
/* Number of clock shifted nano seconds in one NTP interval. */
- u64 xtime_interval;
+ u64 xtime_interval;
/* shifted nano seconds left over when rounding cycle_interval */
- s64 xtime_remainder;
+ s64 xtime_remainder;
/* Raw nano seconds accumulated per NTP interval. */
- u32 raw_interval;
+ u32 raw_interval;
/* Clock shifted nano seconds remainder not stored in xtime.tv_nsec. */
- u64 xtime_nsec;
+ u64 xtime_nsec;
/* Difference between accumulated time and NTP time in ntp
* shifted nano seconds. */
- s64 ntp_error;
+ s64 ntp_error;
/* Shift conversion between clock shifted nano seconds and
* ntp shifted nano seconds. */
- int ntp_error_shift;
+ int ntp_error_shift;
/* The current time */
- struct timespec xtime;
+ struct timespec xtime;
/*
* wall_to_monotonic is what we need to add to xtime (or xtime corrected
* for sub jiffie times) to get to monotonic time. Monotonic is pegged
@@ -64,20 +63,17 @@ struct timekeeper {
* - wall_to_monotonic is no longer the boot time, getboottime must be
* used instead.
*/
- struct timespec wall_to_monotonic;
+ struct timespec wall_to_monotonic;
/* time spent in suspend */
- struct timespec total_sleep_time;
+ struct timespec total_sleep_time;
/* The raw monotonic time for the CLOCK_MONOTONIC_RAW posix clock. */
- struct timespec raw_time;
-
+ struct timespec raw_time;
/* Offset clock monotonic -> clock realtime */
- ktime_t offs_real;
-
+ ktime_t offs_real;
/* Offset clock monotonic -> clock boottime */
- ktime_t offs_boot;
-
+ ktime_t offs_boot;
/* Seqlock for all timekeeper values */
- seqlock_t lock;
+ seqlock_t lock;
};
static struct timekeeper timekeeper;
@@ -547,6 +543,7 @@ u64 timekeeping_max_deferment(void)
{
unsigned long seq;
u64 ret;
+
do {
seq = read_seqbegin(&timekeeper.lock);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] ntp: Fix STA_INS/DEL clearing bug
From: John Stultz
In commit 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d, I
introduced a bug that kept the STA_INS or STA_DEL bit
from being cleared from time_status via adjtimex()
without forcing STA_PLL first.
Usually once the STA_INS is set, it isn't cleared
until the leap second is applied, so its unlikely this
affected anyone. However during testing I noticed it
took some effort to cancel a leap second once STA_INS
was set.
This issue affects 3.4 and up.
Since this isn't urgent (issue is only observed in testing,
the behavior doesn't affect ntpd, nor is a leapsecond due
for at least ~6 months), and we're late in the 3.5-rc
cycle, I'm holding this off for 3.6 merge window,
where I'll then backport to 3.5-stable and 3.4-stable.
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Cochran
CC: Prarit Bhargava
CC: Thomas Gleixner
CC: sta...@vger.kernel.org
Signed-off-by: John Stultz
---
kernel/time/ntp.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 70b33ab..b7fbadc 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -409,7 +409,9 @@ int second_overflow(unsigned long secs)
time_state = TIME_DEL;
break;
case TIME_INS:
- if (secs % 86400 == 0) {
+ if (!(time_status & STA_INS))
+ time_state = TIME_OK;
+ else if (secs % 86400 == 0) {
leap = -1;
time_state = TIME_OOP;
time_tai++;
@@ -418,7 +420,9 @@ int second_overflow(unsigned long secs)
}
break;
case TIME_DEL:
- if ((secs + 1) % 86400 == 0) {
+ if (!(time_status & STA_DEL))
+ time_state = TIME_OK;
+ else if ((secs + 1) % 86400 == 0) {
leap = 1;
time_tai--;
time_state = TIME_WAIT;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] time: Explicitly use u32 instead of int for shift values
Ingo noted that using a u32 instead of int for shift values
would be better to make sure the compiler doesn't unnecessarily
use complex signed arithmetic.
CC: Ingo Molnar
CC: Peter Zijlstra
CC: Richard Cochran
CC: Prarit Bhargava
CC: Thomas Gleixner
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index c2f12aa..4fd83df 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -28,7 +28,7 @@ struct timekeeper {
/* NTP adjusted clock multiplier */
u32 mult;
/* The shift value of the current clocksource. */
- int shift;
+ u32 shift;
/* Number of clock cycles in one NTP interval. */
cycle_t cycle_interval;
/* Number of clock shifted nano seconds in one NTP interval. */
@@ -45,7 +45,7 @@ struct timekeeper {
s64 ntp_error;
/* Shift conversion between clock shifted nano seconds and
* ntp shifted nano seconds. */
- int ntp_error_shift;
+ u32 ntp_error_shift;
/* The current time */
struct timespec xtime;
@@ -960,7 +960,7 @@ static void timekeeping_adjust(s64 offset)
*
* Returns the unconsumed cycles.
*/
-static cycle_t logarithmic_accumulation(cycle_t offset, int shift)
+static cycle_t logarithmic_accumulation(cycle_t offset, u32 shift)
{
u64 nsecps = (u64)NSEC_PER_SEC << timekeeper.shift;
u64 raw_nsecs;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] Time fixes and cleanups for 3.6
Hey Thomas, Since you're offline next week, I wanted to send you my updated queue for the 3.6 merge window. These are mostly the same changes I sent you with my earlier 3.6 pull request mid-last month, but reordered and trimmed down to focus on cleanups (no new features). There is one NTP bug fix, from a change in 3.4, but given its non critical and we're late in the 3.5-rc cycle, I wanted to hold it off for 3.6 and backport it once merged. Since these expect the leapsecond hrtimer/time changes currently in tip/timers/urgent, it is based off of that branch, rather then tip/timers/core. Although tip/timers/core merges fairly cleanly (there's only a minor collision with already upstream 3.5 changes). Let me know if these look ok. With the exception of the NTP fix, the rest can wait till 3.7 if you'd prefer, so they're nothing urgent. thanks -john CC: Ingo Molnar CC: Peter Zijlstra CC: Richard Cochran CC: Prarit Bhargava CC: Thomas Gleixner If you want to git pull: The following changes since commit 5baefd6d84163443215f4a99f6a20f054ef11236: hrtimer: Update hrtimer base offsets each hrtimer_interrupt (2012-07-11 23:34:39 +0200) are available in the git repository at: git://git.linaro.org/people/jstultz/linux.git fortglx/3.6/time for you to fetch changes up to 96dbf98929ac690a7d0d0ad54cf24631763da16c: time: Rework timekeeping functions to take timekeeper ptr as argument (2012-07-13 01:15:46 -0400) John Stultz (8): ntp: Fix STA_INS/DEL clearing bug time: Whitespace cleanups per Ingo's requests time: Explicitly use u32 instead of int for shift values time: Condense timekeeper.xtime into xtime_sec time: Refactor accumulation of nsecs to secs time: Move arch_gettimeoffset() usage into timekeeping_get_ns() time: Move xtime_nsec adjustment underflow handling timekeeping_adjust time: Rework timekeeping functions to take timekeeper ptr as argument kernel/time/ntp.c |8 +- kernel/time/timekeeping.c | 492 - 2 files changed, 273 insertions(+), 227 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/vsyscall: allow seccomp filter in vsyscall=emulate
If a seccomp filter program is installed, older static binaries and
distributions with older libc implementations (glibc 2.13 and earlier)
that rely on vsyscall use will be terminated regardless of the filter
program policy when executing time, gettimeofday, or getcpu. This is
only the case when vsyscall emulation is in use (vsyscall=emulate is the
default).
This patch emulates system call entry inside a vsyscall=emulate trap
such that seccomp can properly evaluate the system call.
Reported-by: Owen Kibel
Signed-off-by: Will Drewry
---
arch/x86/kernel/vsyscall_64.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 7515cf0..433545f 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -139,6 +139,14 @@ static int addr_to_vsyscall_nr(unsigned long addr)
return nr;
}
+static int vsyscall_seccomp(struct task_struct *tsk, int syscall_nr)
+{
+ if (!seccomp_mode(&tsk->seccomp))
+ return 0;
+ task_pt_regs(tsk)->orig_ax = syscall_nr;
+ return __secure_computing(syscall_nr);
+}
+
static bool write_ok_or_segv(unsigned long ptr, size_t size)
{
/*
@@ -174,6 +182,7 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
int vsyscall_nr;
int prev_sig_on_uaccess_error;
long ret;
+ int skip;
/*
* No point in checking CS -- the only way to get here is a user mode
@@ -205,9 +214,6 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
}
tsk = current;
- if (seccomp_mode(&tsk->seccomp))
- do_exit(SIGKILL);
-
/*
* With a real vsyscall, page faults cause SIGSEGV. We want to
* preserve that behavior to make writing exploits harder.
@@ -222,8 +228,13 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
* address 0".
*/
ret = -EFAULT;
+ skip = 0;
switch (vsyscall_nr) {
case 0:
+ skip = vsyscall_seccomp(tsk, __NR_gettimeofday);
+ if (skip)
+ break;
+
if (!write_ok_or_segv(regs->di, sizeof(struct timeval)) ||
!write_ok_or_segv(regs->si, sizeof(struct timezone)))
break;
@@ -234,6 +245,10 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
break;
case 1:
+ skip = vsyscall_seccomp(tsk, __NR_time);
+ if (skip)
+ break;
+
if (!write_ok_or_segv(regs->di, sizeof(time_t)))
break;
@@ -241,6 +256,10 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
break;
case 2:
+ skip = vsyscall_seccomp(tsk, __NR_getcpu);
+ if (skip)
+ break;
+
if (!write_ok_or_segv(regs->di, sizeof(unsigned)) ||
!write_ok_or_segv(regs->si, sizeof(unsigned)))
break;
@@ -253,6 +272,9 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
current_thread_info()->sig_on_uaccess_error = prev_sig_on_uaccess_error;
+ if (skip)
+ goto do_ret;
+
if (ret == -EFAULT) {
/* Bad news -- userspace fed a bad pointer to a vsyscall. */
warn_bad_vsyscall(KERN_INFO, regs,
@@ -271,6 +293,7 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long
address)
regs->ax = ret;
+do_ret:
/* Emulate a ret instruction. */
regs->ip = caller;
regs->sp += 8;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the clk tree with the arm-soc tree
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
drivers/clk/Makefile between commit 4a31bd28e86a ("ARM: nomadik: convert
to generic clock") from the arm-soc tree and commit 8d4d9f52081c ("clk:
add highbank clock support") from the clk tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/clk/Makefile
index 26b6b92,02ffdf6..000
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@@ -3,6 -3,11 +3,12 @@@ obj-$(CONFIG_CLKDEV_LOOKUP)+= clkdev.
obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \
clk-mux.o clk-divider.o clk-fixed-factor.o
# SoCs specific
+obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
+ obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
obj-$(CONFIG_ARCH_MXS)+= mxs/
obj-$(CONFIG_PLAT_SPEAR) += spear/
+ obj-$(CONFIG_ARCH_U300) += clk-u300.o
+ obj-$(CONFIG_ARCH_INTEGRATOR) += versatile/
+
+ # Chip specific
+ obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
pgpd4JbK4jA6M.pgp
Description: PGP signature
Re: [RFC PATCH v3 3/13] memory-hotplug : unify argument of firmware_map_add_early/hotplug
Hi Dave, 2012/07/12 22:40, Dave Hansen wrote: > On 07/11/2012 09:52 PM, Yasuaki Ishimatsu wrote: >> Does the following patch include your comment? If O.K., I will separate >> the patch from the series and send it for bug fix. > > Looks sane to me. It does now mean that the calling conventions for > some of the other firmware_map*() functions are different, but I think > that's OK since they're only used internally to memmap.c. Can I add "Reviewed-by: Dave Hansen" to the patch? Thanks, Yasuaki Ishimatsu > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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/
Re: [PATCH] leds/leds-s3c24xx: use devm_gpio_request
On Fri, Jul 13, 2012 at 9:12 AM, Bryan Wu wrote: > On Wed, Jul 11, 2012 at 5:50 PM, Devendra Naga > wrote: >> Bryan, >> >> This patch is not even compile tested, since my machine crashed, and >> didn't have the ARM toolchain, sorry .. >> > > Thanks, I built it successfully. It looks fine to me. I will apply > this to my for-next branch. > > -Bryan > Thank Bryan, I will set up my cross-toolchain soon.. sorry for not compiling it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 000/187] 3.4.5-stable review
On 2012-07-12 21:24 +0200, Greg KH wrote: > This is the start of the stable review cycle for the 3.4.5 release. > There are 187 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. As has been noted already, some of the patches are actually missing. > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.5-rc1.gz Seems it's not there? Cheers, Sven -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3 3/13] memory-hotplug : unify argument of firmware_map_add_early/hotplug
Hi Dave, 2012/07/12 22:40, Dave Hansen wrote: > On 07/11/2012 09:52 PM, Yasuaki Ishimatsu wrote: >> Does the following patch include your comment? If O.K., I will separate >> the patch from the series and send it for bug fix. > > Looks sane to me. It does now mean that the calling conventions for > some of the other firmware_map*() functions are different, but I think > that's OK since they're only used internally to memmap.c. Thank you for reviewing my patch. I'll send the patch. Thanks, Yasuaki Ishimatsu > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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/
linux-next: build failure after merge of the tty tree
Hi Greg,
After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/char/mwave/mwavedd.c: In function 'register_serial_portandirq':
drivers/char/mwave/mwavedd.c:472:2: error: implicit declaration of function
'serial8250_register_port' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
drivers/misc/ibmasm/uart.c: In function 'ibmasm_register_uart':
drivers/misc/ibmasm/uart.c:57:2: error: implicit declaration of function
'serial8250_register_port' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
Caused by commit 2655a2c76f80 ("8250: use the 8250 register interface not
the legacy one"). Grep is your friend.
I have used the tty tree from next-20120712 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpt5WoBhJpNL.pgp
Description: PGP signature
RE: 82571EB: Detected Hardware Unit Hang
>-Original Message- >From: Joe Jin [mailto:joe@oracle.com] >Sent: Thursday, July 12, 2012 4:46 PM >To: Dave, Tushar N >Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux- >ker...@vger.kernel.org >Subject: Re: 82571EB: Detected Hardware Unit Hang > Thanks for sending full dmesg log. I am still investigating. I think this issue can occur if two PCIe link partner *i.e pcie bridge and pcie device do not have same max payload size. I need 2 more info. 1) PBA number of the card. 2) full lspci -vvv output of entire system 'after you have changed max payload size to 128'. Thanks. -Tushar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MPILIB: Provide count_leading/trailing_zeros() based on arch functions
On Fri, 6 Jul 2012, David Howells wrote: > Provide count_leading/trailing_zeros() macros based on extant arch bit > scanning > functions rather than reimplementing from scratch in MPILIB. > > Whilst we're at it, turn count_foo_zeros(n, x) into n = count_foo_zeros(x). > > Also move the definition to asm-generic as other people may be interested in > using it. Please rebase this against git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9 v3] dmaengine: add an shdma-base library
On Mon, 2012-07-02 at 22:28 +0200, Guennadi Liakhovetski wrote: > Hi Vinod > > On Thu, 28 Jun 2012, Guennadi Liakhovetski wrote: > > > Hi Vinod > > > > On Fri, 25 May 2012, Guennadi Liakhovetski wrote: > > > > > Hi Vinod > > > > > > On Fri, 25 May 2012, Vinod Koul wrote: > > > > [snip] > > > > > > Let me know if you plan to fixing them or I will queue these up for 3.6 > > > > > > Please, queue these patches for the next merge window, we will work on > > > improving the driver after this split. > > > > It's been a month since this mail - do I see it right, that these patches > > are still not in your slave-dma tree? Having them there would (1) get them > > some exposure and testing and (2) eventually speed up building on top of > > them and fixing existing driver's shortcomings. Any approximate idea when > > you'd be able to pull them in? Sorry my bad, I missed them afterwards. I will try them now. I assumed the two series I have in my inbox in on top of these 9 patches. > An update to this patch series: unfortunately, I forgot to include the > very first patch in this series. I'll send it as a reply to this mail. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC V3 2/3] kvm: Note down when cpu relax intercepted or pause loop exited
On 07/13/2012 01:32 AM, Christian Borntraeger wrote:
On 12/07/12 21:18, Raghavendra K T wrote:
+#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
[...]
+ struct {
+ bool cpu_relax_intercepted;
+ bool dy_eligible;
+ } ple;
+#endif
[...]
}
vcpu->run = page_address(page);
+ vcpu->ple.cpu_relax_intercepted = false;
+ vcpu->ple.dy_eligible = false;
This struct is only defined if CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT is set, but
here it
is always accessed. Will break on !x86&& !s390.
Yes! I forgot about archs in init function.
How about having
#ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
vcpu->ple.cpu_relax_intercepted = false;
vcpu->ple.dy_eligible = false;
#endif
This would solve all the problem.
r = kvm_arch_vcpu_init(vcpu);
if (r< 0)
@@ -1577,6 +1579,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
int pass;
int i;
+ me->ple.cpu_relax_intercepted = true;
dito
currently vcpu_on_spin is used only by x86 and s390. so if some other
arch in future uses vcpu_on_spin, I believe they also have to enable
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
what do you think?
otherwise we have to add hook everywhere
/*
* We boost the priority of a VCPU that is runnable but not
* currently running, because it got preempted by something
@@ -1602,6 +1605,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
}
}
}
+ me->ple.cpu_relax_intercepted = false;
again.
maybe define static inline access functions in kvm_host.h that are no-ops
if CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT is not set.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3 5/13] memory-hotplug : does not release memory region in PAGES_PER_SECTION chunks
At 07/09/2012 06:26 PM, Yasuaki Ishimatsu Wrote:
> Since applying a patch(de7f0cba96786c), release_mem_region() has been changed
> as called in PAGES_PER_SECTION chunks because register_memory_resource() is
> called in PAGES_PER_SECTION chunks by add_memory(). But it seems firmware
> dependency. If CRS are written in the PAGES_PER_SECTION chunks in ACPI DSDT
> Table, register_memory_resource() is called in PAGES_PER_SECTION chunks.
> But if CRS are written in the DIMM unit in ACPI DSDT Table,
> register_memory_resource() is called in DIMM unit. So release_mem_region()
> should not be called in PAGES_PER_SECTION chunks. The patch fixes it.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> arch/powerpc/platforms/pseries/hotplug-memory.c | 13 +
> mm/memory_hotplug.c |4 ++--
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> Index: linux-3.5-rc4/mm/memory_hotplug.c
> ===
> --- linux-3.5-rc4.orig/mm/memory_hotplug.c2012-07-03 14:22:03.549198802
> +0900
> +++ linux-3.5-rc4/mm/memory_hotplug.c 2012-07-03 14:22:05.919169458 +0900
> @@ -358,11 +358,11 @@ int __remove_pages(struct zone *zone, un
> BUG_ON(phys_start_pfn & ~PAGE_SECTION_MASK);
> BUG_ON(nr_pages % PAGES_PER_SECTION);
>
> + release_mem_region(phys_start_pfn << PAGE_SHIFT, nr_pages * PAGE_SIZE);
> +
> sections_to_remove = nr_pages / PAGES_PER_SECTION;
> for (i = 0; i < sections_to_remove; i++) {
> unsigned long pfn = phys_start_pfn + i*PAGES_PER_SECTION;
> - release_mem_region(pfn << PAGE_SHIFT,
> -PAGES_PER_SECTION << PAGE_SHIFT);
> ret = __remove_section(zone, __pfn_to_section(pfn));
> if (ret)
> break;
> Index: linux-3.5-rc4/arch/powerpc/platforms/pseries/hotplug-memory.c
> ===
> --- linux-3.5-rc4.orig/arch/powerpc/platforms/pseries/hotplug-memory.c
> 2012-07-03 14:21:45.641422678
> +0900
Hmm, I think you should change your mail client's config.
Thanks
Wen Congyang
> +++ linux-3.5-rc4/arch/powerpc/platforms/pseries/hotplug-memory.c
> 2012-07-03 14:22:05.920169437 +0900
> @@ -77,7 +77,8 @@ static int pseries_remove_memblock(unsig
> {
> unsigned long start, start_pfn;
> struct zone *zone;
> - int ret;
> + int i, ret;
> + int sections_to_remove;
>
> start_pfn = base >> PAGE_SHIFT;
>
> @@ -97,9 +98,13 @@ static int pseries_remove_memblock(unsig
>* to sysfs "state" file and we can't remove sysfs entries
>* while writing to it. So we have to defer it to here.
>*/
> - ret = __remove_pages(zone, start_pfn, memblock_size >> PAGE_SHIFT);
> - if (ret)
> - return ret;
> + sections_to_remove = (memblock_size >> PAGE_SHIFT) / PAGES_PER_SECTION;
> + for (i = 0; i < sections_to_remove; i++) {
> + unsigned long pfn = start_pfn + i * PAGES_PER_SECTION;
> + ret = __remove_pages(zone, start_pfn, PAGES_PER_SECTION);
> + if (ret)
> + return ret;
> + }
>
> /*
>* Update memory regions for memory remove
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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/
Re: [PATCH 1/2] dma: tegra: rename driver and compatible to match with dts
On Mon, 2012-07-02 at 13:52 +0530, Laxman Dewangan wrote: > Rename the compatible name and driver name to match with > tegra dts file and as per clock driver. > > Signed-off-by: Laxman Dewangan Applied both, Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
> acpi_memory_device_remove() has been prepared to remove physical memory.
> But, the function only frees acpi_memory_device currentlry.
>
> The patch adds following functions into acpi_memory_device_remove():
> - offline memory
> - remove physical memory (only return -EBUSY)
> - free acpi_memory_device
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/acpi/acpi_memhotplug.c | 26 +-
> drivers/base/memory.c | 39 +++
> include/linux/memory.h |5 +
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c|8
> 5 files changed, 78 insertions(+), 1 deletion(-)
>
> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
> ===
> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:29.946888653 +0900
> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:43.470719531 +0900
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
> static int acpi_memory_device_remove(struct acpi_device *device, int type)
> {
> struct acpi_memory_device *mem_device = NULL;
> -
> + struct acpi_memory_info *info, *tmp;
> + int result;
> + int node;
>
> if (!device || !acpi_driver_data(device))
> return -EINVAL;
>
> mem_device = acpi_driver_data(device);
> +
> + node = acpi_get_node(mem_device->device->handle);
> +
> + list_for_each_entry_safe(info, tmp, &mem_device->res_list, list) {
> + if (!info->enabled)
> + continue;
> +
> + if (!is_memblk_offline(info->start_addr, info->length)) {
> + result = offline_memory(info->start_addr, info->length);
> + if (result)
> + return result;
> + }
> +
> + result = remove_memory(node, info->start_addr, info->length);
The user may online the memory between offline_memory() and remove_memory().
So I think we should lock memory hotplug before check the memory's status
and release it after remove_memory().
Thanks
Wen Congyang
> + if (result)
> + return result;
> +
> + list_del(&info->list);
> + kfree(info);
> + }
> +
> kfree(mem_device);
>
> return 0;
> Index: linux-3.5-rc6/include/linux/memory_hotplug.h
> ===
> --- linux-3.5-rc6.orig/include/linux/memory_hotplug.h 2012-07-09
> 18:08:29.955888542 +0900
> +++ linux-3.5-rc6/include/linux/memory_hotplug.h 2012-07-09
> 18:08:43.471719518 +0900
> @@ -233,6 +233,7 @@ static inline int is_mem_section_removab
> extern int mem_online_node(int nid);
> extern int add_memory(int nid, u64 start, u64 size);
> extern int arch_add_memory(int nid, u64 start, u64 size);
> +extern int remove_memory(int nid, u64 start, u64 size);
> extern int offline_memory(u64 start, u64 size);
> extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn,
> int nr_pages);
> Index: linux-3.5-rc6/mm/memory_hotplug.c
> ===
> --- linux-3.5-rc6.orig/mm/memory_hotplug.c2012-07-09 18:08:29.953888567
> +0900
> +++ linux-3.5-rc6/mm/memory_hotplug.c 2012-07-09 18:08:43.476719455 +0900
> @@ -659,6 +659,14 @@ out:
> }
> EXPORT_SYMBOL_GPL(add_memory);
>
> +int remove_memory(int nid, u64 start, u64 size)
> +{
> + return -EBUSY;
> +
> +}
> +EXPORT_SYMBOL_GPL(remove_memory);
> +
> +
> #ifdef CONFIG_MEMORY_HOTREMOVE
> /*
> * A free page on the buddy free lists (not the per-cpu lists) has PageBuddy
> Index: linux-3.5-rc6/drivers/base/memory.c
> ===
> --- linux-3.5-rc6.orig/drivers/base/memory.c 2012-07-09 18:08:29.947888640
> +0900
> +++ linux-3.5-rc6/drivers/base/memory.c 2012-07-09 18:10:54.880076739
> +0900
> @@ -70,6 +70,45 @@ void unregister_memory_isolate_notifier(
> }
> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>
> +bool is_memblk_offline(unsigned long start, unsigned long size)
> +{
> + struct memory_block *mem = NULL;
> + struct mem_section *section;
> + unsigned long start_pfn, end_pfn;
> + unsigned long pfn, section_nr;
> +
> + start_pfn = PFN_DOWN(start);
> + end_pfn = start_pfn + PFN_DOWN(start);
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> +
Re: [PATCH 2/2] dma: tegra: fix residual calculation for cyclic case
On Mon, 2012-07-02 at 10:02 -0600, Stephen Warren wrote: > On 07/02/2012 02:22 AM, Laxman Dewangan wrote: > > In cyclic mode of DMA, the byte transferred can be more > > than the requested size and in this case, calculating > > residuals based on the current position of DMA transfer to > > bytes requested i.e. bytes required to transfer to reach > > bytes requested from current DMA position. > > > > Signed-off-by: Laxman Dewangan > > This makes sense to me, although I wonder if details like this aren't > something that the dmaengine core should be handling. No core doesn't know anything about the how much you are transferring and where you are. That is the driver to calculate and provide. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] leds/leds-s3c24xx: use devm_gpio_request
On Wed, Jul 11, 2012 at 5:50 PM, Devendra Naga wrote: > why? > because if the led_classdev_register fails we wont do gpio free > because using devm_ functions, there is no need for error paths > > Signed-off-by: Devendra Naga > --- > Bryan, > > This patch is not even compile tested, since my machine crashed, and > didn't have the ARM toolchain, sorry .. > Thanks, I built it successfully. It looks fine to me. I will apply this to my for-next branch. -Bryan > And i think this patch is legit not as that pci_set_drvdata one :( > drivers/leds/leds-s3c24xx.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/leds/leds-s3c24xx.c b/drivers/leds/leds-s3c24xx.c > index e120640..942f0ea 100644 > --- a/drivers/leds/leds-s3c24xx.c > +++ b/drivers/leds/leds-s3c24xx.c > @@ -65,7 +65,6 @@ static int s3c24xx_led_remove(struct platform_device *dev) > struct s3c24xx_gpio_led *led = pdev_to_gpio(dev); > > led_classdev_unregister(&led->cdev); > - gpio_free(led->pdata->gpio); > > return 0; > } > @@ -92,7 +91,7 @@ static int s3c24xx_led_probe(struct platform_device *dev) > > led->pdata = pdata; > > - ret = gpio_request(pdata->gpio, "S3C24XX_LED"); > + ret = devm_gpio_request(&dev->dev, pdata->gpio, "S3C24XX_LED"); > if (ret < 0) > return ret; > > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-leds" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Bryan Wu Kernel Developer+86.186-168-78255 Mobile Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Made core dump functionality optional
On Thu, 2012-07-12 at 13:22 -0700, Alex Kelly wrote: > Sorry it took me so long to reply to this: > > 1. *Should* I change the option to CONFIG_CORE_DUMP ? I agree with Josh > that in terms of the existing codebase, either way makes sense, but I'll > defer to your judgment if you think I should change it. Yeah, I agree. > > 2. Is there a particular maintainer I should send this to if I hope to get > it pushed upstream? > I think Andrew Morton will take the patch. 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: [RFC PATCH v3 2/13] memory-hotplug : add physical memory hotplug code to acpi_memory_device_remove
At 07/09/2012 06:24 PM, Yasuaki Ishimatsu Wrote:
> acpi_memory_device_remove() has been prepared to remove physical memory.
> But, the function only frees acpi_memory_device currentlry.
>
> The patch adds following functions into acpi_memory_device_remove():
> - offline memory
> - remove physical memory (only return -EBUSY)
> - free acpi_memory_device
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/acpi/acpi_memhotplug.c | 26 +-
> drivers/base/memory.c | 39 +++
> include/linux/memory.h |5 +
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c|8
> 5 files changed, 78 insertions(+), 1 deletion(-)
>
> Index: linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c
> ===
> --- linux-3.5-rc6.orig/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:29.946888653 +0900
> +++ linux-3.5-rc6/drivers/acpi/acpi_memhotplug.c 2012-07-09
> 18:08:43.470719531 +0900
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -452,12 +453,35 @@ static int acpi_memory_device_add(struct
> static int acpi_memory_device_remove(struct acpi_device *device, int type)
> {
> struct acpi_memory_device *mem_device = NULL;
> -
> + struct acpi_memory_info *info, *tmp;
> + int result;
> + int node;
>
> if (!device || !acpi_driver_data(device))
> return -EINVAL;
>
> mem_device = acpi_driver_data(device);
> +
> + node = acpi_get_node(mem_device->device->handle);
> +
> + list_for_each_entry_safe(info, tmp, &mem_device->res_list, list) {
> + if (!info->enabled)
> + continue;
> +
> + if (!is_memblk_offline(info->start_addr, info->length)) {
> + result = offline_memory(info->start_addr, info->length);
> + if (result)
> + return result;
> + }
> +
> + result = remove_memory(node, info->start_addr, info->length);
> + if (result)
> + return result;
> +
> + list_del(&info->list);
> + kfree(info);
> + }
> +
> kfree(mem_device);
>
> return 0;
> Index: linux-3.5-rc6/include/linux/memory_hotplug.h
> ===
> --- linux-3.5-rc6.orig/include/linux/memory_hotplug.h 2012-07-09
> 18:08:29.955888542 +0900
> +++ linux-3.5-rc6/include/linux/memory_hotplug.h 2012-07-09
> 18:08:43.471719518 +0900
> @@ -233,6 +233,7 @@ static inline int is_mem_section_removab
> extern int mem_online_node(int nid);
> extern int add_memory(int nid, u64 start, u64 size);
> extern int arch_add_memory(int nid, u64 start, u64 size);
> +extern int remove_memory(int nid, u64 start, u64 size);
Here should be:
#ifdef CONFIG_MEMORY_HOTREMOVE
extern int remove_memory(int nid, u64 start, u64 size);
#else
static int inline remove_memory(int nid, u64 start, u64 size)
{
return -EBUSY;
}
#endif
> extern int offline_memory(u64 start, u64 size);
> extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn,
> int nr_pages);
> Index: linux-3.5-rc6/mm/memory_hotplug.c
> ===
> --- linux-3.5-rc6.orig/mm/memory_hotplug.c2012-07-09 18:08:29.953888567
> +0900
> +++ linux-3.5-rc6/mm/memory_hotplug.c 2012-07-09 18:08:43.476719455 +0900
> @@ -659,6 +659,14 @@ out:
> }
> EXPORT_SYMBOL_GPL(add_memory);
>
> +int remove_memory(int nid, u64 start, u64 size)
> +{
> + return -EBUSY;
> +
> +}
> +EXPORT_SYMBOL_GPL(remove_memory);
We only need to implement this function when CONFIG_MEMORY_HOTREMOVE
is defined here.
Thanks
Wen Congyang
> +
> +
> #ifdef CONFIG_MEMORY_HOTREMOVE
> /*
> * A free page on the buddy free lists (not the per-cpu lists) has PageBuddy
> Index: linux-3.5-rc6/drivers/base/memory.c
> ===
> --- linux-3.5-rc6.orig/drivers/base/memory.c 2012-07-09 18:08:29.947888640
> +0900
> +++ linux-3.5-rc6/drivers/base/memory.c 2012-07-09 18:10:54.880076739
> +0900
> @@ -70,6 +70,45 @@ void unregister_memory_isolate_notifier(
> }
> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>
> +bool is_memblk_offline(unsigned long start, unsigned long size)
> +{
> + struct memory_block *mem = NULL;
> + struct mem_section *section;
> + unsigned long start_pfn, end_pfn;
> + unsigned long pfn, section_nr;
> +
> + start_pfn = PFN_DOWN(start);
> + end_pfn = star
Re: linux-next: manual merge of the slave-dma tree with the arm tree
On Mon, 2012-07-02 at 13:16 +1000, Stephen Rothwell wrote:
> Hi Vinod,
>
> Today's linux-next merge of the slave-dma tree got conflicts in
> drivers/dma/Kconfig and drivers/dma/Makefile between commit 06dba53e6fcf
> ("dmaengine: add OMAP DMA engine driver") from the arm tree and commit
> c6da0ba8dfc8 ("dmaengine: mmp_tdma: add mmp tdma support") from the
> slave-dma tree.
Thanks, Looks like Russell has merged the OMAP changes into his tree?
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RESEND PATCH 1/1] clk: add DT support for clock gating control
On 07/12/2012 08:08 AM, Sebastian Hesselbarh wrote:
> On 07/12/2012 02:14 PM, Rob Herring wrote:
>>> +Required child properties:
>>> +- reg : should contain the individual bit and polarity to control
>>> +the clock gate. A polarity of 0 means that by setting the
>>> +bit to 1 the clock passes through the clock gate while
>>> +setting the bit to 0 disables the clock. Any other value
>>> + for polarity inverts the meaning of the control bit.
>>
>> This is a bit of overloading reg to specify the polarity.
>
> Well, yes it is overloading but still matches reg somehow, as the
> extra information is required to access the resource. But I agree,
> expecially wrt more-than-one-bit clk-gate (see below).
>
You can define your own property names.
>>> +/* SATA clock gate with different parent clock */
>>> +cg_sata: clockgate@3 {
>>> +reg =<3 0>; /* register bit 3, normal polarity */
>>> +clocks =<&sata_clk>;
>>> +};
>>
>> I'm not sure I like the node per bit. What about a bit mask for valid
>> bits and polarities. Then add a clock cell to specify the bit or index.
>>
>> i.MX has 2-bit enable fields for its leaf clocks, so how and if you
>> would support that is something to think about.
>
> Yeah, I thought of "what if the clk_gate needs to be enabled with more
> than 1 bit" already. But this is a short-comming of the current clk-gate
> implementation.
What's implemented in Linux should not define the binding. The binding
should describe the hardware.
> Just to get it right, i.MX requires to set more than one bit to change
> the state of the gate for one leaf clock?
It's basically ON, OFF, and "ON in run/OFF in wfi".
Perhaps the iMX case is unique enough we don't try to make it use a
common binding.
> If this is true, that would require a change of the generic clk-gate
> anyway.
True, but not your problem to implement. A binding doesn't necessarily
mean there is a full Linux implementation. We just don't want to create
something only to find others need something completely different.
Rob
> I had a look at pinctrl-bindings.txt maybe this is the way to go for
> clock gating control, too. That would require clk-gate to handle an
> 'active' and 'gated' state and leave it to a clock gate control to
> actually set the required bits in any registers. This would allow
> other special implementations of clock gating controllers to reuse
> clk-gate DT description. Additionally, there could be a
> simple-clock-gating-control that can set states by reg address and
> for each controlled gate a mask, enable value, and disable value.
>
> Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next] r8169: Remove rtl_ocpdr_cond
Francois Romieu [mailto:rom...@fr.zoreil.com] [...] > > W/o firmware does not seem to make a difference. > > # ping -qf -l 4 -s 81 -c 60 10.0.3.1 > PING 10.0.3.1 (10.0.3.1) 81(109) bytes of data. > > --- 10.0.3.1 ping statistics --- > 60 packets transmitted, 60 received, 0% packet loss, time 153ms > rtt min/avg/max/mdev = 0.047/0.064/0.117/0.016 ms, pipe 4, > ipg/ewma 2.607/0.058 ms # ping -qf -l 4 -s 81 -c 60 192.168.94.20 PING 192.168.94.20 (192.168.94.20) 81(109) bytes of data. --- 192.168.94.20 ping statistics --- 60 packets transmitted, 57 received, 5% packet loss, time 1ms rtt min/avg/max/mdev = 0.028/0.040/0.101/0.011 ms, pipe 4, ipg/ewma 0.021/0.035 ms > # ping -qf -l 4 -s 82 -c 60 10.0.3.1 > > PING 10.0.3.1 (10.0.3.1) 82(110) bytes of data. > > --- 10.0.3.1 ping statistics --- > 60 packets transmitted, 60 received, 0% packet loss, time 3ms > rtt min/avg/max/mdev = 0.195/0.210/0.281/0.018 ms, pipe 4, > ipg/ewma 0.057/0.205 ms # ping -qf -l 4 -s 82 -c 60 192.168.94.20 PING 192.168.94.20 (192.168.94.20) 82(110) bytes of data. --- 192.168.94.20 ping statistics --- 60 packets transmitted, 60 received, 0% packet loss, time 2ms rtt min/avg/max/mdev = 0.151/0.173/0.247/0.020 ms, pipe 4, ipg/ewma 0.048/0.168 ms > It would translate into a 127/128 cutoff after inclusion of the FCS. > > Any idea ? > The attatched file is my log. It seems fine. a.log Description: Binary data
Re: feature-removal-schedule entry from 2009
On Wed, Jul 11, 2012 at 11:15:20AM -0500, Rob Landley wrote: > IRQF_SAMPLE_RANDOM is 3 years past its sell-by date in > feature-removal-schedule: > > What: IRQF_SAMPLE_RANDOM > Check: IRQF_SAMPLE_RANDOM > When: July 2009 > > Why:Many of IRQF_SAMPLE_RANDOM users are technically bogus as > entropy sources in the kernel's current entropy model. To > resolve this, every input point to the kernel's entropy pool > needs to better document the type of entropy source it actually > is. This will be replaced with additional add_*_randomness > functions in drivers/char/random.c > > Who:Robin Getz > & Matt Mackall > > There are 12 remaining uses under drivers/ and 14 more under arch/, the > rest of the hits look like infrastructure implementing it. > > Should I run those files through bother-maintainer.pl and try to get > people to stop it, or is there a plan underway I don't know about? I was going to deal with that in the new /dev/random tree; once those changes go in, IRQF_SAMPLE_RANDOM effectively becomes a no-op. But I'd prefer that the ordering be that we get the new sample_interrupt_randomness() changes in first, and then remove the IRQF_SAMPLE_RANDOM. I've just been slammed with work, processing patches for the ext4 merge window, and kernel summit planning, and quite frankly, I considered this to be relatively low priority --- especially since we no shortage of IRQF_* flag bits, and once the new sample_interrupt_randomness() goes in, the flag is a complete no-op. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3] usb/host/ehci-hub: Fix the issue EG20T USB host controller has long resuming time, when pen drive is attached.
Intel EG20T USB host controller does not send SOF in resuming time after suspending, if the FLR bit was not cleared. When pen drive is attached, the controller has a long resuming time to try re-connect it. This patch clear the FLR bit in suspending time for fixing the issue. Signed-off-by: Tomoya MORINAGA --- v3: Update comments from Alan Stern Add comment in the source code. v2: Update comments from Alan Stern Add patch description Always clear the STS_FLR flag. --- drivers/usb/host/ehci-hub.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index fc9e7cc..278b589 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -318,6 +318,13 @@ static int ehci_bus_suspend (struct usb_hcd *hcd) ehci_readl(ehci, &ehci->regs->intr_enable); ehci->next_statechange = jiffies + msecs_to_jiffies(10); + + /* Intel EG20T USB host controller does not send SOF +* in resuming time after suspending, if the FLR bit was not cleared. +* Therefore clear the FLR bit in here. +*/ + ehci_writel(ehci, STS_FLR, &ehci->regs->status); + spin_unlock_irq (&ehci->lock); /* ehci_work() may have re-enabled the watchdog timer, which we do not -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM mini-summit
On Wed, Jul 11, 2012 at 4:28 AM, Arnd Bergmann wrote: > On Wednesday 11 July 2012, James Bottomley wrote: >> Hi All, >> >> We have set aside the second day of the kernel summit (Tuesday 28 >> August) as mini-summit day. So far we have only the PCI mini summit on >> this day, so if you can think of other topics, please send them to the >> kernel summit discuss list: >> >> ksummit-2012-disc...@lists.linux-foundation.org >> >> Looking at the available rooms, we think we can run about four or five >> mini summits. >> >> As an added incentive, mini summit organisers get to pick who they >> invite and all the people they pick will get an automatic invitation to >> the third day of the kernel summit (but not the core first day) and the >> evening events. > > There is a lot of interest in having another ARM mini-summit, as we had last > year. Previously, Grant Likely organized this with Olof and me, but right now > Grant is in an extended offline period and Olof is currently on vacation > as well. Will Deacon already contacted me and he is interested in helping > out with organizing the mini-summit, so the two of us could be the primary > contacts, with Grant and Olof joining in as time permits. ACK. I'll be back home next week and should have more time to spend on it from there on out. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] staging: sbe-2t3e3: Remove code that will never execute
This patch removes all references of "if 0" blocks in the sbe-2t3e3 driver.
Signed-off-by: Marcos Paulo de Souza
---
drivers/staging/sbe-2t3e3/2t3e3.h|3 --
drivers/staging/sbe-2t3e3/cpld.c | 15 -
drivers/staging/sbe-2t3e3/ctrl.c | 19 +++
drivers/staging/sbe-2t3e3/dc.c | 17 --
drivers/staging/sbe-2t3e3/exar7250.c | 40 +++
drivers/staging/sbe-2t3e3/exar7300.c | 17 --
drivers/staging/sbe-2t3e3/intr.c | 60 ++
drivers/staging/sbe-2t3e3/io.c | 21
8 files changed, 10 insertions(+), 182 deletions(-)
diff --git a/drivers/staging/sbe-2t3e3/2t3e3.h
b/drivers/staging/sbe-2t3e3/2t3e3.h
index fe9f086..383f2cf 100644
--- a/drivers/staging/sbe-2t3e3/2t3e3.h
+++ b/drivers/staging/sbe-2t3e3/2t3e3.h
Just fix the commit message fo sbr-2t3e3 to sbe-2t3e3.
@@ -801,9 +801,6 @@ u32 cpld_read(struct channel *sc, u32 reg);
void cpld_set_crc(struct channel *, u32);
void cpld_start_intr(struct channel *);
void cpld_stop_intr(struct channel *);
-#if 0
-void cpld_led_onoff(struct channel *, u32, u32, u32, u32);
-#endif
void cpld_set_clock(struct channel *sc, u32 mode);
void cpld_set_scrambler(struct channel *, u32);
void cpld_select_panel(struct channel *, u32);
diff --git a/drivers/staging/sbe-2t3e3/cpld.c b/drivers/staging/sbe-2t3e3/cpld.c
index b0fc2dd..cc2b54d 100644
--- a/drivers/staging/sbe-2t3e3/cpld.c
+++ b/drivers/staging/sbe-2t3e3/cpld.c
@@ -41,14 +41,6 @@ static inline void cpld_clear_bit(struct channel *channel,
unsigned reg, u32 bit
void cpld_init(struct channel *sc)
{
u32 val;
-#if 0
- /* reset LIU and Framer */
- val = cpld_val_map[SBE_2T3E3_CPLD_VAL_LIU_FRAMER_RESET][sc->h.slot];
- cpld_write(sc, SBE_2T3E3_CPLD_REG_STATIC_RESET, val);
- udelay(1); /* TODO - how long? */
- val = 0;
- cpld_write(sc, SBE_2T3E3_CPLD_REG_STATIC_RESET, val);
-#endif
/* PCRA */
val = SBE_2T3E3_CPLD_VAL_CRC32 |
@@ -109,13 +101,6 @@ void cpld_start_intr(struct channel *sc)
val = SBE_2T3E3_CPLD_VAL_INTERRUPT_FROM_ETHERNET_ENABLE |
SBE_2T3E3_CPLD_VAL_INTERRUPT_FROM_FRAMER_ENABLE;
cpld_write(sc, SBE_2T3E3_CPLD_REG_PIER, val);
-#if 0
- /*
- do you want to hang up your computer?
- ENABLE REST OF INTERRUPTS !!!
- you have been warned :).
- */
-#endif
}
void cpld_stop_intr(struct channel *sc)
diff --git a/drivers/staging/sbe-2t3e3/ctrl.c b/drivers/staging/sbe-2t3e3/ctrl.c
index d9dd216..a5825d7 100644
--- a/drivers/staging/sbe-2t3e3/ctrl.c
+++ b/drivers/staging/sbe-2t3e3/ctrl.c
@@ -230,11 +230,9 @@ void t3e3_port_get_stats(struct channel *sc,
result = exar7250_read(sc,
SBE_2T3E3_FRAMER_REG_E3_RX_CONFIGURATION_STATUS_2);
sc->s.LOF = result & SBE_2T3E3_FRAMER_VAL_E3_RX_LOF ? 1 : 0;
sc->s.OOF = result & SBE_2T3E3_FRAMER_VAL_E3_RX_OOF ? 1 : 0;
-#if 0
- sc->s.LOS = result & SBE_2T3E3_FRAMER_VAL_E3_RX_LOS ? 1 : 0;
-#else
+
cpld_LOS_update(sc);
-#endif
+
sc->s.AIS = result & SBE_2T3E3_FRAMER_VAL_E3_RX_AIS ? 1 : 0;
sc->s.FERF = result & SBE_2T3E3_FRAMER_VAL_E3_RX_FERF ? 1 : 0;
break;
@@ -243,11 +241,9 @@ void t3e3_port_get_stats(struct channel *sc,
case SBE_2T3E3_FRAME_TYPE_T3_M13:
result = exar7250_read(sc,
SBE_2T3E3_FRAMER_REG_T3_RX_CONFIGURATION_STATUS);
sc->s.AIS = result & SBE_2T3E3_FRAMER_VAL_T3_RX_AIS ? 1 : 0;
-#if 0
- sc->s.LOS = result & SBE_2T3E3_FRAMER_VAL_T3_RX_LOS ? 1 : 0;
-#else
+
cpld_LOS_update(sc);
-#endif
+
sc->s.IDLE = result & SBE_2T3E3_FRAMER_VAL_T3_RX_IDLE ? 1 : 0;
sc->s.OOF = result & SBE_2T3E3_FRAMER_VAL_T3_RX_OOF ? 1 : 0;
@@ -322,10 +318,6 @@ void t3e3_if_config(struct channel *sc, u32 cmd, char *set,
*rlen = sizeof(ret->u.data);
break;
case SBE_2T3E3_PORT_WRITE_REGS:
-#if 0
- printk(KERN_DEBUG "SBE_2T3E3_PORT_WRITE_REGS, 0x%x, 0x%x,
0x%x\n",
- ((int*)data)[0], ((int*)data)[1], ((int*)data)[2]);
-#endif
t3e3_reg_write(sc, data);
*rlen = 0;
break;
@@ -336,9 +328,6 @@ void t3e3_if_config(struct channel *sc, u32 cmd, char *set,
*rlen = 0;
break;
}
-
- /* turn on interrupt */
- /* cpld_start_intr(sc); */
}
void t3e3_sc_init(struct channel *sc)
diff --git a/drivers/staging/sbe-2t3e3/dc.c b/drivers/staging/sbe-2t3e3/dc.c
index e897a43..9e81d90 100644
--- a/drivers/staging/sbe-2t3e3/dc.c
+++ b/drivers/staging/sbe-2t3e3/dc.c
@@ -63,14 +63,6 @@ void dc_init(struct channel *sc)
if (sc->p.loopback == SBE_2T3E3_LOOPBACK_ETHERNET)
sc->p.loopback = SBE_2T3E3_LOOPBACK_NONE;
-#if 0 /* No need to clear this register - and i
[PATCH] staging: sbe-2t3e3: Remove code that will never execute
This patch removes all references of "if 0" blocks in the sbr-2t3e3.
Signed-off-by: Marcos Paulo de Souza
---
drivers/staging/sbe-2t3e3/2t3e3.h|3 --
drivers/staging/sbe-2t3e3/cpld.c | 15 -
drivers/staging/sbe-2t3e3/ctrl.c | 19 +++
drivers/staging/sbe-2t3e3/dc.c | 17 --
drivers/staging/sbe-2t3e3/exar7250.c | 40 +++
drivers/staging/sbe-2t3e3/exar7300.c | 17 --
drivers/staging/sbe-2t3e3/intr.c | 60 ++
drivers/staging/sbe-2t3e3/io.c | 21
8 files changed, 10 insertions(+), 182 deletions(-)
diff --git a/drivers/staging/sbe-2t3e3/2t3e3.h
b/drivers/staging/sbe-2t3e3/2t3e3.h
index fe9f086..383f2cf 100644
--- a/drivers/staging/sbe-2t3e3/2t3e3.h
+++ b/drivers/staging/sbe-2t3e3/2t3e3.h
@@ -801,9 +801,6 @@ u32 cpld_read(struct channel *sc, u32 reg);
void cpld_set_crc(struct channel *, u32);
void cpld_start_intr(struct channel *);
void cpld_stop_intr(struct channel *);
-#if 0
-void cpld_led_onoff(struct channel *, u32, u32, u32, u32);
-#endif
void cpld_set_clock(struct channel *sc, u32 mode);
void cpld_set_scrambler(struct channel *, u32);
void cpld_select_panel(struct channel *, u32);
diff --git a/drivers/staging/sbe-2t3e3/cpld.c b/drivers/staging/sbe-2t3e3/cpld.c
index b0fc2dd..cc2b54d 100644
--- a/drivers/staging/sbe-2t3e3/cpld.c
+++ b/drivers/staging/sbe-2t3e3/cpld.c
@@ -41,14 +41,6 @@ static inline void cpld_clear_bit(struct channel *channel,
unsigned reg, u32 bit
void cpld_init(struct channel *sc)
{
u32 val;
-#if 0
- /* reset LIU and Framer */
- val = cpld_val_map[SBE_2T3E3_CPLD_VAL_LIU_FRAMER_RESET][sc->h.slot];
- cpld_write(sc, SBE_2T3E3_CPLD_REG_STATIC_RESET, val);
- udelay(1); /* TODO - how long? */
- val = 0;
- cpld_write(sc, SBE_2T3E3_CPLD_REG_STATIC_RESET, val);
-#endif
/* PCRA */
val = SBE_2T3E3_CPLD_VAL_CRC32 |
@@ -109,13 +101,6 @@ void cpld_start_intr(struct channel *sc)
val = SBE_2T3E3_CPLD_VAL_INTERRUPT_FROM_ETHERNET_ENABLE |
SBE_2T3E3_CPLD_VAL_INTERRUPT_FROM_FRAMER_ENABLE;
cpld_write(sc, SBE_2T3E3_CPLD_REG_PIER, val);
-#if 0
- /*
- do you want to hang up your computer?
- ENABLE REST OF INTERRUPTS !!!
- you have been warned :).
- */
-#endif
}
void cpld_stop_intr(struct channel *sc)
diff --git a/drivers/staging/sbe-2t3e3/ctrl.c b/drivers/staging/sbe-2t3e3/ctrl.c
index d9dd216..a5825d7 100644
--- a/drivers/staging/sbe-2t3e3/ctrl.c
+++ b/drivers/staging/sbe-2t3e3/ctrl.c
@@ -230,11 +230,9 @@ void t3e3_port_get_stats(struct channel *sc,
result = exar7250_read(sc,
SBE_2T3E3_FRAMER_REG_E3_RX_CONFIGURATION_STATUS_2);
sc->s.LOF = result & SBE_2T3E3_FRAMER_VAL_E3_RX_LOF ? 1 : 0;
sc->s.OOF = result & SBE_2T3E3_FRAMER_VAL_E3_RX_OOF ? 1 : 0;
-#if 0
- sc->s.LOS = result & SBE_2T3E3_FRAMER_VAL_E3_RX_LOS ? 1 : 0;
-#else
+
cpld_LOS_update(sc);
-#endif
+
sc->s.AIS = result & SBE_2T3E3_FRAMER_VAL_E3_RX_AIS ? 1 : 0;
sc->s.FERF = result & SBE_2T3E3_FRAMER_VAL_E3_RX_FERF ? 1 : 0;
break;
@@ -243,11 +241,9 @@ void t3e3_port_get_stats(struct channel *sc,
case SBE_2T3E3_FRAME_TYPE_T3_M13:
result = exar7250_read(sc,
SBE_2T3E3_FRAMER_REG_T3_RX_CONFIGURATION_STATUS);
sc->s.AIS = result & SBE_2T3E3_FRAMER_VAL_T3_RX_AIS ? 1 : 0;
-#if 0
- sc->s.LOS = result & SBE_2T3E3_FRAMER_VAL_T3_RX_LOS ? 1 : 0;
-#else
+
cpld_LOS_update(sc);
-#endif
+
sc->s.IDLE = result & SBE_2T3E3_FRAMER_VAL_T3_RX_IDLE ? 1 : 0;
sc->s.OOF = result & SBE_2T3E3_FRAMER_VAL_T3_RX_OOF ? 1 : 0;
@@ -322,10 +318,6 @@ void t3e3_if_config(struct channel *sc, u32 cmd, char *set,
*rlen = sizeof(ret->u.data);
break;
case SBE_2T3E3_PORT_WRITE_REGS:
-#if 0
- printk(KERN_DEBUG "SBE_2T3E3_PORT_WRITE_REGS, 0x%x, 0x%x,
0x%x\n",
- ((int*)data)[0], ((int*)data)[1], ((int*)data)[2]);
-#endif
t3e3_reg_write(sc, data);
*rlen = 0;
break;
@@ -336,9 +328,6 @@ void t3e3_if_config(struct channel *sc, u32 cmd, char *set,
*rlen = 0;
break;
}
-
- /* turn on interrupt */
- /* cpld_start_intr(sc); */
}
void t3e3_sc_init(struct channel *sc)
diff --git a/drivers/staging/sbe-2t3e3/dc.c b/drivers/staging/sbe-2t3e3/dc.c
index e897a43..9e81d90 100644
--- a/drivers/staging/sbe-2t3e3/dc.c
+++ b/drivers/staging/sbe-2t3e3/dc.c
@@ -63,14 +63,6 @@ void dc_init(struct channel *sc)
if (sc->p.loopback == SBE_2T3E3_LOOPBACK_ETHERNET)
sc->p.loopback = SBE_2T3E3_LOOPBACK_NONE;
-#if 0 /* No need to clear this register - and it may be in use */
- /*
-* BOOT_ROM_SERIAL_ROM_AND
[PATCH] regulator: s2mps11: Use array to save pointer to rdev
The number of regulator is known at compile time, use array to save pointer to
rdev makes the code simpler.
Signed-off-by: Axel Lin
---
drivers/regulator/s2mps11.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 4669dc9..926f9c8 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -24,7 +24,7 @@
#include
struct s2mps11_info {
- struct regulator_dev **rdev;
+ struct regulator_dev *rdev[S2MPS11_REGULATOR_MAX];
int ramp_delay2;
int ramp_delay34;
@@ -236,9 +236,8 @@ static __devinit int s2mps11_pmic_probe(struct
platform_device *pdev)
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct sec_platform_data *pdata = dev_get_platdata(iodev->dev);
struct regulator_config config = { };
- struct regulator_dev **rdev;
struct s2mps11_info *s2mps11;
- int i, ret, size;
+ int i, ret;
unsigned char ramp_enable, ramp_reg = 0;
if (!pdata) {
@@ -251,13 +250,6 @@ static __devinit int s2mps11_pmic_probe(struct
platform_device *pdev)
if (!s2mps11)
return -ENOMEM;
- size = sizeof(struct regulator_dev *) * S2MPS11_REGULATOR_MAX;
- s2mps11->rdev = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
- if (!s2mps11->rdev) {
- return -ENOMEM;
- }
-
- rdev = s2mps11->rdev;
platform_set_drvdata(pdev, s2mps11);
s2mps11->ramp_delay2 = pdata->buck2_ramp_delay;
@@ -297,12 +289,12 @@ static __devinit int s2mps11_pmic_probe(struct
platform_device *pdev)
config.init_data = pdata->regulators[i].initdata;
config.driver_data = s2mps11;
- rdev[i] = regulator_register(®ulators[i], &config);
- if (IS_ERR(rdev[i])) {
- ret = PTR_ERR(rdev[i]);
+ s2mps11->rdev[i] = regulator_register(®ulators[i], &config);
+ if (IS_ERR(s2mps11->rdev[i])) {
+ ret = PTR_ERR(s2mps11->rdev[i]);
dev_err(&pdev->dev, "regulator init failed for %d\n",
i);
- rdev[i] = NULL;
+ s2mps11->rdev[i] = NULL;
goto err;
}
}
@@ -310,8 +302,7 @@ static __devinit int s2mps11_pmic_probe(struct
platform_device *pdev)
return 0;
err:
for (i = 0; i < S2MPS11_REGULATOR_MAX; i++)
- if (rdev[i])
- regulator_unregister(rdev[i]);
+ regulator_unregister(s2mps11->rdev[i]);
return ret;
}
@@ -319,12 +310,10 @@ err:
static int __devexit s2mps11_pmic_remove(struct platform_device *pdev)
{
struct s2mps11_info *s2mps11 = platform_get_drvdata(pdev);
- struct regulator_dev **rdev = s2mps11->rdev;
int i;
for (i = 0; i < S2MPS11_REGULATOR_MAX; i++)
- if (rdev[i])
- regulator_unregister(rdev[i]);
+ regulator_unregister(s2mps11->rdev[i]);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: How to use the generic thermal sysfs.
On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote: > Hi, > > > -Original Message- > > From: Wei Ni [mailto:w...@nvidia.com] > > Sent: Thursday, July 12, 2012 3:53 PM > > To: Zhang, Rui; Brown, Len; a...@linux-foundation.org; kh...@linux-fr.org; > > j...@perches.com; R, Durgadoss > > Cc: linux-kernel@vger.kernel.org; linux-te...@ger.kernel.org; > > acour...@nvidia.com > > Subject: How to use the generic thermal sysfs. > > > > Hi, all > > I'm working on the tegra thermal throttling upstream issue. > > The tegra30 board use the nct1008 as the thermal sensor, and the lm90 is > > the sensor driver. We want to use the generic thermal sysfs. > > > > My question is where should we register the thermal zone device? We may > > have two place to do it: > > 1. register it in the sensor driver, such as lm90.c > > In this way, the sensor driver doesn't need to export any APIs, such as > > get_temp. > > This approach is preferred. > > > 2. register in my tegra thermal framework. > > In this way, the sensor driver need to export some APIs, which are used > > to register the ops and do any other things. > > What do you mean by "my tegra thermal framework" ? Where does the source > file for this sit in the mainline kernel ? > I have the same question. It sounds like that you want to use the tegra thermal framework to do thermal management instead of the generic thermal layer, right? IMO, the purpose of the generic thermal layer is 1) do kernel thermal management 2) export unique sysfs I/F to userspace so that users/userspace applications can take over the thermal management. what is the benefit to have another driver to do thermal management in kernel? If the current thermal management in the generic thermal layer can not work well on your platform, it is a good chance to enhance the kernel thermal manager. :) thanks, rui > > > > How should I do it? > > > > And in current codes, there have the event notification, in the form of > > a netlink event. But it's difficult to be used in the kernel, it's > > normally for the communication with user-space. How about to add a > > notify call chain for it? So when the sensor has irq alert, it can send > > a notify to my thermal framework in kernel. > > We are working on a notification API from any generic sensor driver to > the thermal framework. > Please have a look at the 'notify_thermal_framework' API in the patch here: > http://www.spinics.net/lists/linux-acpi/msg36049.html > > Thanks, > Durga > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 22/68] ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
On Thu, Jul 12, 2012 at 10:38:35PM -0300, Herton Ronaldo Krzesinski wrote: > On Thu, Jul 12, 2012 at 04:01:56PM -0700, Greg Kroah-Hartman wrote: > > From: Greg KH > > > > 3.0-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Mohammed Shafi Shajakhan > > > > commit f18e3c6b67f448ec47b3a5b242789bd3d5644879 upstream. > > > > "ath9k: Fix softlockup in AR9485" with commit id > > 64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported > > issue, yet its better to avoid the possible infinite loop > > in ar9003_get_pll_sqsum_dvc by having a timeout as suggested > > by ath9k maintainers. > > http://www.spinics.net/lists/linux-wireless/msg92126.html. > > Based on my testing PLL's locking measurement is done in > > ~200us (2 iterations). > > Missing the rest of the patch here. Yeah, quilt went crazy and messed things up, the originals are fine, but something went really wrong when the mbox was created, sorry. A number of different patches didn't go through properly. 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: [ 66/68] mm: Hold a file reference in madvise_remove
On Thu, Jul 12, 2012 at 04:02:40PM -0700, Greg Kroah-Hartman wrote:
> From: Greg KH
>
> 3.0-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Andy Lutomirski
>
> commit 9ab4233dd08036fe34a89c7dc6f47a8bf2eb29eb upstream.
>
> Otherwise the code races with munmap (causing a use-after-free
> of the vma) or with close (causing a use-after-free of the struct
> file).
>
> The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
> mmap_sem i_mutex deadlock")
>
> [bwh: Backported to 3.2:
> - Adjust context
> - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
> [luto: Backported to 3.0: Adjust context]
Didn't want to be annoying, but as I went looking sequentially,
I found missing diffs one by one... anyway this should be the last.
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
[]'s
Herton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 54/68] tracing: change CPU ring buffer state from tracing_cpumask
On Thu, Jul 12, 2012 at 04:02:28PM -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Vaibhav Nagarnaik > > commit 71babb2705e2203a64c27ede13ae3508a0d2c16c upstream. > > According to Documentation/trace/ftrace.txt: > > tracing_cpumask: > > This is a mask that lets the user only trace > on specified CPUS. The format is a hex string > representing the CPUS. > > The tracing_cpumask currently doesn't affect the tracing state of > per-CPU ring buffers. > > This patch enables/disables CPU recording as its corresponding bit in > tracing_cpumask is set/unset. > > Link: > http://lkml.kernel.org/r/1336096792-25373-3-git-send-email-vnagarn...@google.com Missing patch. > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 51/68] PCI: EHCI: fix crash during suspend on ASUS computers
On Thu, Jul 12, 2012 at 04:02:25PM -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- Missing also the diff/"signoff area" on this one. > > From: Alan Stern > > commit dbf0e4c7257f8d684ec1a3c919853464293de66e upstream. > > Quite a few ASUS computers experience a nasty problem, related to the > EHCI controllers, when going into system suspend. It was observed > that the problem didn't occur if the controllers were not put into the > D3 power state before starting the suspend, and commit > 151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during > suspend on ASUS computers) was created to do this. > > It turned out this approach messed up other computers that didn't have > the problem -- it prevented USB wakeup from working. Consequently > commit c2fb8a3fa25513de8fedb38509b1f15a5bbee47b (USB: add > NO_D3_DURING_SLEEP flag and revert 151b61284776be2) was merged; it > reverted the earlier commit and added a whitelist of known good board > names. > > Now we know the actual cause of the problem. Thanks to AceLan Kao for > tracking it down. > > According to him, an engineer at ASUS explained that some of their > BIOSes contain a bug that was added in an attempt to work around a > problem in early versions of Windows. When the computer goes into S3 > suspend, the BIOS tries to verify that the EHCI controllers were first > quiesced by the OS. Nothing's wrong with this, but the BIOS does it > by checking that the PCI COMMAND registers contain 0 without checking > the controllers' power state. If the register isn't 0, the BIOS > assumes the controller needs to be quiesced and tries to do so. This > involves making various MMIO accesses to the controller, which don't > work very well if the controller is already in D3. The end result is > a system hang or memory corruption. > > Since the value in the PCI COMMAND register doesn't matter once the > controller has been suspended, and since the value will be restored > anyway when the controller is resumed, we can work around the BIOS bug > simply by setting the register to 0 during system suspend. This patch > (as1590) does so and also reverts the second commit mentioned above, > which is now unnecessary. > > In theory we could do this for every PCI device. However to avoid > introducing new problems, the patch restricts itself to EHCI host > controllers. > > Finally the affected systems can suspend with USB wakeup working > properly. > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 22/68] ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc
On Thu, Jul 12, 2012 at 04:01:56PM -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Mohammed Shafi Shajakhan > > commit f18e3c6b67f448ec47b3a5b242789bd3d5644879 upstream. > > "ath9k: Fix softlockup in AR9485" with commit id > 64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported > issue, yet its better to avoid the possible infinite loop > in ar9003_get_pll_sqsum_dvc by having a timeout as suggested > by ath9k maintainers. > http://www.spinics.net/lists/linux-wireless/msg92126.html. > Based on my testing PLL's locking measurement is done in > ~200us (2 iterations). Missing the rest of the patch here. > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] aio: Export symbols and struct kiocb_batch for in kernel aio usage
Hi James, On 07/13/2012 01:50 AM, James Bottomley wrote: On Thu, 2012-07-12 at 23:35 +0800, Asias He wrote: This is useful for people who want to use aio in kernel, e.g. vhost-blk. Signed-off-by: Asias He --- fs/aio.c| 37 ++--- include/linux/aio.h | 21 + 2 files changed, 39 insertions(+), 19 deletions(-) Um, I think you don't quite understand how aio in the kernel would work; it's not as simple as just exporting the interfaces. There's already a (very long) patch set from oracle to do this so loop can use aio: http://marc.info/?l=linux-fsdevel&m=133312234313122 Oh, I did not see this patch set. Thanks for pointing it out! This bit hasn't merged, right? I'd love to use the aio_kernel_() interface if it is merged. It will simply vhost-blk. Due to lack of better kernel aio interface, we are currently doing io_setup, io_submit, etc. in vhost-blk on our own. -- Asias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.2.23
I'm announcing the release of the 3.2.23 kernel. All users of the 3.2 kernel series should upgrade. The updated 3.2.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.2.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git Ben. Makefile |2 +- arch/arm/kernel/smp.c | 10 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S|2 +- arch/powerpc/xmon/xmon.c |2 +- drivers/block/umem.c | 40 drivers/gpu/drm/i915/i915_dma.c| 37 +-- drivers/md/persistent-data/dm-space-map-checker.c | 54 ++- drivers/md/persistent-data/dm-space-map-disk.c | 11 ++- .../md/persistent-data/dm-transaction-manager.c| 11 ++- drivers/md/raid10.c| 12 ++- drivers/md/raid5.c | 10 +- drivers/mtd/nand/cafe_nand.c |2 +- drivers/net/bonding/bond_main.c|9 +- drivers/net/dummy.c|5 +- drivers/net/ethernet/emulex/benet/be_main.c|5 +- drivers/net/ethernet/marvell/sky2.c| 10 +- drivers/net/wireless/ath/ath.h |1 + drivers/net/wireless/ath/ath9k/hw.c|2 +- drivers/net/wireless/ath/ath9k/recv.c |3 +- drivers/net/wireless/ath/key.c |4 + drivers/net/wireless/mwifiex/11n_rxreorder.c |5 +- drivers/net/wireless/mwifiex/11n_rxreorder.h |7 ++ drivers/net/wireless/mwifiex/cfg80211.c| 21 ++-- drivers/net/wireless/mwifiex/wmm.c | 12 ++- drivers/net/wireless/rtlwifi/rtl8192cu/sw.c|3 + drivers/target/tcm_fc/tfc_sess.c |3 +- fs/btrfs/tree-log.c|6 ++ fs/cifs/connect.c |9 +- fs/ocfs2/file.c|4 +- fs/open.c |6 +- fs/splice.c| 35 --- fs/udf/super.c | 102 include/linux/aio.h|1 + include/linux/splice.h |8 +- include/net/cipso_ipv4.h | 29 +- include/net/sch_generic.h |7 +- kernel/relay.c |5 +- kernel/trace/trace.c |8 +- mm/madvise.c | 16 ++- mm/shmem.c |3 +- net/bridge/br_if.c |1 + net/bridge/br_netlink.c|2 +- net/bridge/br_private.h|1 + net/core/ethtool.c |1 + net/core/netpoll.c | 11 ++- net/core/skbuff.c |3 +- net/core/sock.c|7 +- net/ipv6/route.c | 41 ++-- net/l2tp/l2tp_eth.c|2 + net/l2tp/l2tp_ip.c |9 +- net/mac80211/rx.c |5 +- net/nfc/nci/ntf.c |4 +- net/nfc/rawsock.c |5 +- sound/pci/hda/patch_sigmatel.c |4 +- sound/soc/codecs/tlv320aic3x.c |4 +- sound/soc/codecs/tlv320aic3x.h |1 + 56 files changed, 439 insertions(+), 184 deletions(-) Andy Lutomirski (1): mm: Hold a file reference in madvise_remove Anton Blanchard (1): powerpc/xmon: Use cpumask iterator to avoid warning Ben Hutchings (1): Linux 3.2.23 Bing Zhao (1): mwifiex: fix wrong return values in add_virtual_intf() error cases Chris Mason (1): Btrfs: run delayed directory updates during log replay Dan Carpenter (1): mtd: cafe_nand: fix an & vs | mistake Dan Rosenberg (1): NFC: Prevent multiple buffer overflows in NCI Daniel Vetter (1): drm/i915: kick any firmware framebuffers before claiming the gtt Eric Dumazet (8): splice: fix racy pipe->buffers uses NFC: Return from rawsock_release when sk is NULL net: l2tp_eth: fix kernel panic on rmmod l2tp_eth l2tp: fix a race in l2tp_ip_sendmsg() be2net: fix a race in be_xmit() dummy: fix rcu_sched self-detected stalls bonding: Fix corrupted queue_mapping netpoll: fix netpoll_send_udp() bugs Felix Fietkau (1): ath9k: fix dynamic WEP rela
Re: [PATCH 0/5] Add vhost-blk support
Hello Jeff, On 07/13/2012 12:06 AM, Jeff Moyer wrote: Asias He writes: Hi folks, This patchset adds vhost-blk support. vhost-blk is a in kernel virito-blk device accelerator. Compared to userspace virtio-blk implementation, vhost-blk gives about 5% to 15% performance improvement. Asias He (5): aio: Export symbols and struct kiocb_batch for in kernel aio usage eventfd: Export symbol eventfd_file_create() vhost: Make vhost a separate module vhost-net: Use VHOST_NET_FEATURES for vhost-net vhost-blk: Add vhost-blk support I only saw patches 0 and 1. Where are the other 4? If the answer is, "not on lkml," then please resend them, CC'ing lkml. I did send all the 0-5 patches to lkml, but I somehow messed up the thread. Will CC you next time. I'd like to be able to see the usage of the aio routines. OK. It'd be nice if you could review. Thanks. -- Asias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3] memory-hotplug: fix kswapd looping forever problem
On Thu, Jul 12, 2012 at 02:01:54PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2012 11:50:49 +0900
> Minchan Kim wrote:
>
> > When hotplug offlining happens on zone A, it starts to mark freed page
> > as MIGRATE_ISOLATE type in buddy for preventing further allocation.
> > (MIGRATE_ISOLATE is very irony type because it's apparently on buddy
> > but we can't allocate them).
> > When the memory shortage happens during hotplug offlining,
> > current task starts to reclaim, then wake up kswapd.
> > Kswapd checks watermark, then go sleep because current
> > zone_watermark_ok_safe
> > doesn't consider MIGRATE_ISOLATE freed page count.
> > Current task continue to reclaim in direct reclaim path without kswapd's
> > helping.
> > The problem is that zone->all_unreclaimable is set by only kswapd
> > so that current task would be looping forever like below.
> >
> > __alloc_pages_slowpath
> > restart:
> > wake_all_kswapd
> > rebalance:
> > __alloc_pages_direct_reclaim
> > do_try_to_free_pages
> > if global_reclaim && !all_unreclaimable
> > return 1; /* It means we did did_some_progress
> > */
> > skip __alloc_pages_may_oom
> > should_alloc_retry
> > goto rebalance;
> >
> > If we apply KOSAKI's patch[1] which doesn't depends on kswapd
> > about setting zone->all_unreclaimable, we can solve this problem
> > by killing some task in direct reclaim path. But it doesn't wake up kswapd,
> > still.
> > It could be a problem still if other subsystem needs GFP_ATOMIC request.
> > So kswapd should consider MIGRATE_ISOLATE when it calculate free pages
> > BEFORE going sleep.
> >
> > This patch counts the number of MIGRATE_ISOLATE page block and
> > zone_watermark_ok_safe will consider it if the system has such blocks
> > (fortunately, it's very rare so no problem in POV overhead and kswapd is
> > never
> > hotpath).
> >
> > Copy/modify from Mel's quote
> > "
> > Ideal solution would be "allocating" the pageblock.
> > It would keep the free space accounting as it is but historically,
> > memory hotplug didn't allocate pages because it would be difficult to
> > detect if a pageblock was isolated or if part of some balloon.
> > Allocating just full pageblocks would work around this, However,
> > it would play very badly with CMA.
> > "
> >
> > [1] http://lkml.org/lkml/2012/6/14/74
> >
> > ...
> >
> > +#ifdef CONFIG_MEMORY_ISOLATION
> > +static inline unsigned long nr_zone_isolate_freepages(struct zone *zone)
> > +{
> > + unsigned long nr_pages = 0;
> > +
> > + if (unlikely(zone->nr_pageblock_isolate)) {
> > + nr_pages = zone->nr_pageblock_isolate * pageblock_nr_pages;
> > + }
> > + return nr_pages;
> > +}
>
> That's pretty verbose. I couldn't resist fiddling with it ;)
>
> > +#else
> > +static inline unsigned long nr_zone_isolate_freepages(struct zone *zone)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
> > bool zone_watermark_ok(struct zone *z, int order, unsigned long mark,
> > int classzone_idx, int alloc_flags)
> > {
> > @@ -1633,6 +1655,14 @@ bool zone_watermark_ok_safe(struct zone *z, int
> > order, unsigned long mark,
> > if (z->percpu_drift_mark && free_pages < z->percpu_drift_mark)
> > free_pages = zone_page_state_snapshot(z, NR_FREE_PAGES);
> >
> > + /*
> > +* If the zone has MIGRATE_ISOLATE type free page,
> > +* we should consider it. nr_zone_isolate_freepages is never
> > +* accurate so kswapd might not sleep although she can.
> > +* But it's more desirable for memory hotplug rather than
> > +* forever sleep which cause livelock in direct reclaim path.
> > +*/
>
> I had a go at clarifying this comment. Please review the result.
>
> > + free_pages -= nr_zone_isolate_freepages(z);
> > return __zone_watermark_ok(z, order, mark, classzone_idx, alloc_flags,
> > free_pages);
> > }
> > @@ -4397,6 +4427,7 @@ static void __paginginit free_area_init_core(struct
> > pglist_data *pgdat,
> > lruvec_init(&zone->lruvec, zone);
> > zap_zone_vm_stats(zone);
> > zone->flags = 0;
> > + zone->nr_pageblock_isolate = 0;
> > if (!size)
> > continue;
> >
> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index fb482cf..64abb33 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/page_isolation.c
> > @@ -8,6 +8,31 @@
> > #include
> > #include "internal.h"
> >
> > +/* called by holding zone->lock */
> > +static void set_pageblock_isolate(struct zone *zone, struct page *page)
> > +{
> > + BUG_ON(page_zone(page) != zone);
>
> Well. If this is the case then why not eliminate this function's
> `zone' argument?
>
> > + if (get_pageblock_migratetype(page) == MIGRATE_ISOLATE)
> > + return;
> > +
> > + set_pageblock_migratetype(page, MIGRATE_ISOLATE);
> > + zone->nr_pageblock_isolate+
[PATCH 1/2] staging: comedi: dt282x: remove the outw wrapper macros
The macros 'update_dacsr', 'update_adcsr', and 'update_supcsr' all use
the 'devpriv' macro which uses a local variable of a specific name and
yeilds a pointer derived from that name. They are also just wrappers
around simple 'outw' calls. Remove the macros.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/dt282x.c | 55 +
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/comedi/drivers/dt282x.c
b/drivers/staging/comedi/drivers/dt282x.c
index 4af3343..1f0b40e 100644
--- a/drivers/staging/comedi/drivers/dt282x.c
+++ b/drivers/staging/comedi/drivers/dt282x.c
@@ -255,11 +255,8 @@ struct dt282x_private {
*Some useless abstractions
*/
#define chan_to_DAC(a) ((a)&1)
-#define update_dacsr(a)outw(devpriv->dacsr|(a),
dev->iobase+DT2821_DACSR)
-#define update_adcsr(a)outw(devpriv->adcsr|(a),
dev->iobase+DT2821_ADCSR)
#define mux_busy() (inw(dev->iobase+DT2821_ADCSR)&DT2821_MUXBUSY)
#define ad_done() (inw(dev->iobase+DT2821_ADCSR)&DT2821_ADDONE)
-#define update_supcsr(a) outw(devpriv->supcsr|(a), dev->iobase+DT2821_SUPCSR)
/*
*danger! macro abuse... a is the expression to wait on, and b is
@@ -317,7 +314,7 @@ static void dt282x_ao_dma_interrupt(struct comedi_device
*dev)
int i;
struct comedi_subdevice *s = dev->subdevices + 1;
- update_supcsr(DT2821_CLRDMADNE);
+ outw(devpriv->supcsr | DT2821_CLRDMADNE, dev->iobase + DT2821_SUPCSR);
if (!s->async->prealloc_buf) {
printk(KERN_ERR "async->data disappeared. dang!\n");
@@ -350,7 +347,7 @@ static void dt282x_ai_dma_interrupt(struct comedi_device
*dev)
int ret;
struct comedi_subdevice *s = dev->subdevices;
- update_supcsr(DT2821_CLRDMADNE);
+ outw(devpriv->supcsr | DT2821_CLRDMADNE, dev->iobase + DT2821_SUPCSR);
if (!s->async->prealloc_buf) {
printk(KERN_ERR "async->data disappeared. dang!\n");
@@ -387,7 +384,7 @@ static void dt282x_ai_dma_interrupt(struct comedi_device
*dev)
/* XXX probably wrong */
if (!devpriv->ntrig) {
devpriv->supcsr &= ~(DT2821_DDMA);
- update_supcsr(0);
+ outw(devpriv->supcsr, dev->iobase + DT2821_SUPCSR);
}
#endif
/* restart the channel */
@@ -513,7 +510,8 @@ static irqreturn_t dt282x_interrupt(int irq, void *d)
s->async->events |= COMEDI_CB_EOA;
} else {
if (supcsr & DT2821_SCDN)
- update_supcsr(DT2821_STRIG);
+ outw(devpriv->supcsr | DT2821_STRIG,
+ dev->iobase + DT2821_SUPCSR);
}
handled = 1;
}
@@ -534,7 +532,8 @@ static void dt282x_load_changain(struct comedi_device *dev,
int n,
for (i = 0; i < n; i++) {
chan = CR_CHAN(chanlist[i]);
range = CR_RANGE(chanlist[i]);
- update_adcsr((range << 4) | (chan));
+ outw(devpriv->adcsr | (range << 4) | chan,
+ dev->iobase + DT2821_ADCSR);
}
outw(n - 1, dev->iobase + DT2821_CHANCSR);
}
@@ -553,15 +552,16 @@ static int dt282x_ai_insn_read(struct comedi_device *dev,
/* XXX should we really be enabling the ad clock here? */
devpriv->adcsr = DT2821_ADCLK;
- update_adcsr(0);
+ outw(devpriv->adcsr, dev->iobase + DT2821_ADCSR);
dt282x_load_changain(dev, 1, &insn->chanspec);
- update_supcsr(DT2821_PRLD);
+ outw(devpriv->supcsr | DT2821_PRLD, dev->iobase + DT2821_SUPCSR);
wait_for(!mux_busy(), comedi_error(dev, "timeout\n"); return -ETIME;);
for (i = 0; i < insn->n; i++) {
- update_supcsr(DT2821_STRIG);
+ outw(devpriv->supcsr | DT2821_STRIG,
+ dev->iobase + DT2821_SUPCSR);
wait_for(ad_done(), comedi_error(dev, "timeout\n");
return -ETIME;);
@@ -718,7 +718,8 @@ static int dt282x_ai_cmd(struct comedi_device *dev, struct
comedi_subdevice *s)
/* external trigger */
devpriv->supcsr = DT2821_ERRINTEN | DT2821_DS0 | DT2821_DS1;
}
- update_supcsr(DT2821_CLRDMADNE | DT2821_BUFFB | DT2821_ADCINIT);
+ outw(devpriv->supcsr | DT2821_CLRDMADNE | DT2821_BUFFB | DT2821_ADCINIT,
+ dev->iobase + DT2821_SUPCSR);
devpriv->ntrig = cmd->stop_arg * cmd->scan_end_arg;
devpriv->nread = devpriv->ntrig;
@@ -729,7 +730,7 @@ static int dt282x_ai_cmd(struct comedi_device *dev, struct
comedi_subdevice *s)
if (devpriv->ntrig) {
prep_ai_dma(dev, 1, 0);
devpriv->supcsr |= DT2821_DDMA;
- update_supcsr(0);
+ outw(devpriv->supcsr, dev->iobase + DT2821_SUPCSR);
}
devpriv
[PATCH 0/2] staging: comedi: remove the devpriv and thisboard macros
The macros 'devpriv' and 'thisboard' rely on a local variable having a specific name and yeild pointers derived from that variable. Replace the macros with local variables where used and use to comedi_board() helper to get the 'thisboard' pointer. The dt282x driver needs some initial cleanup to remove some macros that use the 'devpriv' macro. There are still a couple comedi drivers that have the macros but they are pretty tangled up and require a bit more work. Unfortunately this patch adds quite a few lines-of-code to the drivers. But, it cleans up the CodingStyle issue pointed out in Chapter 12: 2) macros that depend on having a local variable with a magic name: #define FOO(val) bar(index, val) might look like a good thing, but it's confusing as hell when one reads the code and it's prone to breakage from seemingly innocent changes. H Hartley Sweeten (2): staging: comedi: dt282x: remove the outw wrapper macros staging: comedi: remove the devpriv and thisboard macros .../staging/comedi/drivers/addi-data/addi_common.c | 19 +++- .../staging/comedi/drivers/addi-data/addi_eeprom.c | 2 + .../comedi/drivers/addi-data/hwdrv_apci035.c | 14 +++ .../comedi/drivers/addi-data/hwdrv_apci1032.c | 11 +- .../comedi/drivers/addi-data/hwdrv_apci1500.c | 21 +++- .../comedi/drivers/addi-data/hwdrv_apci1516.c | 17 ++- .../comedi/drivers/addi-data/hwdrv_apci1564.c | 16 +++ .../comedi/drivers/addi-data/hwdrv_apci16xx.c | 8 ++ .../comedi/drivers/addi-data/hwdrv_apci2016.c | 12 ++ .../comedi/drivers/addi-data/hwdrv_apci2032.c | 14 +++ .../comedi/drivers/addi-data/hwdrv_apci2200.c | 19 +++- .../comedi/drivers/addi-data/hwdrv_apci3120.c | 42 +-- .../comedi/drivers/addi-data/hwdrv_apci3200.c | 27 - .../comedi/drivers/addi-data/hwdrv_apci3501.c | 18 +++ .../comedi/drivers/addi-data/hwdrv_apci3xxx.c | 18 +++ drivers/staging/comedi/drivers/adl_pci9111.c | 36 -- drivers/staging/comedi/drivers/adl_pci9118.c | 55 +- drivers/staging/comedi/drivers/adq12b.c| 10 +- drivers/staging/comedi/drivers/adv_pci1710.c | 45 +++- drivers/staging/comedi/drivers/adv_pci1723.c | 20 ++-- drivers/staging/comedi/drivers/adv_pci_dio.c | 22 +++- drivers/staging/comedi/drivers/aio_aio12_8.c | 8 +- drivers/staging/comedi/drivers/aio_iiro_16.c | 11 -- drivers/staging/comedi/drivers/amplc_dio200.c | 10 +- drivers/staging/comedi/drivers/amplc_pc236.c | 12 +- drivers/staging/comedi/drivers/amplc_pc263.c | 11 +- drivers/staging/comedi/drivers/amplc_pci224.c | 9 +- drivers/staging/comedi/drivers/amplc_pci230.c | 3 +- drivers/staging/comedi/drivers/cb_das16_cs.c | 4 +- drivers/staging/comedi/drivers/cb_pcidas.c | 2 +- drivers/staging/comedi/drivers/cb_pcidda.c | 27 ++--- drivers/staging/comedi/drivers/cb_pcidio.c | 11 +- drivers/staging/comedi/drivers/cb_pcimdas.c| 23 ++-- drivers/staging/comedi/drivers/cb_pcimdda.c| 29 +++-- drivers/staging/comedi/drivers/comedi_bond.c | 26 ++--- drivers/staging/comedi/drivers/comedi_parport.c| 16 ++- drivers/staging/comedi/drivers/comedi_test.c | 17 ++- drivers/staging/comedi/drivers/contec_pci_dio.c| 6 +- drivers/staging/comedi/drivers/daqboard2000.c | 27 - drivers/staging/comedi/drivers/das08.c | 8 +- drivers/staging/comedi/drivers/das08_cs.c | 4 +- drivers/staging/comedi/drivers/das16.c | 19 +++- drivers/staging/comedi/drivers/das16m1.c | 14 ++- drivers/staging/comedi/drivers/das1800.c | 41 +-- drivers/staging/comedi/drivers/das6402.c | 11 +- drivers/staging/comedi/drivers/das800.c| 29 +++-- drivers/staging/comedi/drivers/dt2801.c| 28 +++-- drivers/staging/comedi/drivers/dt2811.c| 9 +- drivers/staging/comedi/drivers/dt2814.c| 8 +- drivers/staging/comedi/drivers/dt2815.c| 8 +- drivers/staging/comedi/drivers/dt282x.c| 122 + drivers/staging/comedi/drivers/dt3000.c| 28 - drivers/staging/comedi/drivers/dt9812.c| 13 ++- drivers/staging/comedi/drivers/dyna_pci10xx.c | 18 ++- drivers/staging/comedi/drivers/fl512.c | 9 +- drivers/staging/comedi/drivers/icp_multi.c | 36 -- drivers/staging/comedi/drivers/ii_pci20kc.c| 10 +- drivers/staging/comedi/drivers/jr3_pci.c | 5 +- drivers/staging/comedi/drivers/me4000.c| 55 -- drivers/staging/comedi/drivers/me4000.h| 4 - drivers/staging/comedi/drivers/me_daq.c| 27 +++-- drivers/staging/comedi/drivers/mpc624.c| 6 +- drivers/staging/comedi/drivers/mpc8260cpm.c| 11 -- drivers/staging/comedi/drivers/multiq3.c
Re: [PATCH 0/6] Fix for leapsecond caused hrtimer/futex issue (updated)
On 07/10/2012 04:00 PM, John Stultz wrote:
On 07/10/2012 03:43 PM, John Stultz wrote:
Over the weekend, Thomas got a chance to review the leap second fix
in more detail and had a few additional changes he wanted to make
to improve performance as well as style.
So this iteration includes his modifications.
Once merged, I'll be working to get the backports finished as quickly
as I can and sent to -stable.
Once again, here's the test case I've been using to stress test
leapsecond insertion/deletion (the deletion testing is new since last
round).
Prarit noticed a small bug with the test case. We're not initializing
the timespec tv_nsec value before sleeping, so in some cases
clock_nanosleep will return -EINVAL.
This version fixes this and cleans up some of the timespec/timeval usage.
thanks
-john
/* Leap second stress test
* by: john stultz (johns...@us.ibm.com)
* (C) Copyright IBM 2012
* Licensed under the GPLv2
*
* This test signals the kernel to insert a leap second
* every day at midnight GMT. This allows for stessing the
* kernel's leap-second behavior, as well as how well applications
* handle the leap-second discontinuity.
*
* Usage: leap-a-day [-s]
*
* Options:
* -s: Each iteration, set the date to 10 seconds before midnight GMT.
* This speeds up the number of leapsecond transitions tested,
* but because it calls settimeofday frequently, advancing the
* time by 24 hours every ~16 seconds, it may cause application
* disruption.
*
* Other notes: Disabling NTP prior to running this is advised, as the two
* may conflict in thier commands to the kernel.
*
* To build:
* $ gcc leap-a-day.c -o leap-a-day -lrt
*/
#include
#include
#include
#include
#include
#include
#include
#define NSEC_PER_SEC 10ULL
/* returns 1 if a <= b, 0 otherwise */
static inline int in_order(struct timespec a, struct timespec b)
{
if(a.tv_sec < b.tv_sec)
return 1;
if(a.tv_sec > b.tv_sec)
return 0;
if(a.tv_nsec > b.tv_nsec)
return 0;
return 1;
}
struct timespec timespec_add(struct timespec ts, unsigned long long ns)
{
ts.tv_nsec += ns;
while(ts.tv_nsec >= NSEC_PER_SEC) {
ts.tv_nsec -= NSEC_PER_SEC;
ts.tv_sec++;
}
return ts;
}
char* time_state_str(int state)
{
switch (state) {
case TIME_OK: return "TIME_OK";
case TIME_INS: return "TIME_INS";
case TIME_DEL: return "TIME_DEL";
case TIME_OOP: return "TIME_OOP";
case TIME_WAIT: return "TIME_WAIT";
case TIME_BAD: return "TIME_BAD";
}
return "ERROR";
}
/* clear NTP time_status & time_state */
void clear_time_state(void)
{
struct timex tx;
int ret;
/*
* XXX - The fact we have to call this twice seems
* to point to a slight issue in the kernel's ntp state
* managment. Needs to be investigated further.
*/
tx.modes = ADJ_STATUS;
tx.status = STA_PLL;
ret = adjtimex(&tx);
tx.modes = ADJ_STATUS;
tx.status = 0;
ret = adjtimex(&tx);
}
/* Make sure we cleanup on ctrl-c */
void handler(int unused)
{
clear_time_state();
exit(0);
}
/* Test for known hrtimer failure */
void test_hrtimer_failure(void)
{
struct timespec now, target;
clock_gettime(CLOCK_REALTIME, &now);
target = timespec_add(now, NSEC_PER_SEC/2);
clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &target, NULL);
clock_gettime(CLOCK_REALTIME, &now);
if (!in_order(target, now)) {
printf("Note: hrtimer early expiration failure observed.\n");
}
}
int main(int argc, char** argv)
{
int settime = 0;
int insert = 1;
signal(SIGINT, handler);
signal(SIGKILL, handler);
printf("This runs continuously. Press ctrl-c to stop\n");
/* Process arguments */
if (argc > 1) {
if (!strncmp(argv[1], "-s", 2)) {
printf("Setting time to speed up testing\n");
settime = 1;
} else {
printf("Usage: %s [-s]\n", argv[0]);
printf(" -s: Set time to right before leap second each iteration\n");
}
}
printf("\n");
while (1) {
int ret;
struct timespec ts;
struct timex tx;
time_t now, next_leap;
/* Get the current time */
clock_gettime(CLOCK_REALTIME, &ts);
/* Calculate the next possible leap second 23:59:60 GMT */
next_leap = ts.tv_sec;
next_leap += 86400 - (next_leap % 86400);
if (settime) {
struct timeval tv;
tv.tv_sec = next_leap - 10;
tv.tv_usec = 0;
settimeofday(&tv, NULL);
printf("Setting time to %s", ctime(&tv.tv_sec));
}
/* Reset NTP time state */
clear_time_state();
/* Set the leap second insert flag */
tx.modes = ADJ_STATUS;
if (insert)
tx.status = STA_INS;
else
tx.status = STA_DEL;
ret = adjtimex(&tx);
if (ret < 0 ) {
printf("Error: Problem setting STA_INS/STA_DEL!: %s\n",
time_state_str(ret));
return -1;
}
/* Validate STA_INS was set */
ret = adjtimex(&tx);
if (tx.status != STA_INS && tx.status != STA_DEL) {
printf("Error: STA_INS/STA_DEL not set!: %s\n",
time_state_str(ret));
return -
Re: [PATCH 00/13] rbtree updates
On Thu, Jul 12, 2012 at 7:12 AM, Peter Zijlstra wrote: > On Wed, 2012-07-11 at 18:12 -0700, Michel Lespinasse wrote: >> >> In __rb_erase_color(), some of the cases are more complicated than you drew >> however, because some node colors aren't known. > > Right, the wikipedia article draws them blank, I couldn't come up with a > 3rd case, although maybe we can annotate them like (P) to mean blank.. Ah, good idea, I adopted that :) > Yes, very nice.. someday when I'm bored I might expand the comments with > the reason why we're doing the given operation. There is a brief comment at the start of the loop that indicates which rbtree invariants might be violated at that point; so someone could deduce that we're trying to either fix these or move towards the root until they get fixed. But yeah, this is never explicitly explained. > Also, I was sorely tempted to rename your tmp1,tmp2 variables to sl and > sr. This could be done, but you'd *still* need one extra temporary, so you'd end up with sl, sr and tmp. Which is fine, I guess, but I preferred to have one less variable around. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 06/12] rbtree: break out of rb_insert_color loop after tree rotation
It is a well known property of rbtrees that insertion never requires
more than two tree rotations. In our implementation, after one loop
iteration identified one or two necessary tree rotations, we would iterate
and look for more. However at that point the node's parent would always
be black, which would cause us to exit the loop.
We can make the code flow more obvious by just adding a break statement
after the tree rotations, where we know we are done. Additionally, in the
cases where two tree rotations are necessary, we don't have to update the
'node' pointer as it wouldn't be used until the next loop iteration, which
we now avoid due to this break statement.
Signed-off-by: Michel Lespinasse
---
lib/rbtree.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index ccada9a..12abb8a 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -109,18 +109,15 @@ void rb_insert_color(struct rb_node *node, struct rb_root
*root)
}
}
- if (parent->rb_right == node)
- {
- register struct rb_node *tmp;
+ if (parent->rb_right == node) {
__rb_rotate_left(parent, root);
- tmp = parent;
parent = node;
- node = tmp;
}
rb_set_black(parent);
rb_set_red(gparent);
__rb_rotate_right(gparent, root);
+ break;
} else {
{
register struct rb_node *uncle =
gparent->rb_left;
@@ -134,18 +131,15 @@ void rb_insert_color(struct rb_node *node, struct rb_root
*root)
}
}
- if (parent->rb_left == node)
- {
- register struct rb_node *tmp;
+ if (parent->rb_left == node) {
__rb_rotate_right(parent, root);
- tmp = parent;
parent = node;
- node = tmp;
}
rb_set_black(parent);
rb_set_red(gparent);
__rb_rotate_left(gparent, root);
+ break;
}
}
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/12] rbtree: adjust root color in rb_insert_color() only when necessary
The root node of an rbtree must always be black. However, rb_insert_color()
only needs to maintain this invariant when it has been broken - that is,
when it exits the loop due to the current (red) node being the root.
In all other cases (exiting after tree rotations, or exiting due to
an existing black parent) the invariant is already satisfied, so there
is no need to adjust the root node color.
Signed-off-by: Michel Lespinasse
---
lib/rbtree.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index 12abb8a..d0be5fc 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -91,8 +91,21 @@ void rb_insert_color(struct rb_node *node, struct rb_root
*root)
{
struct rb_node *parent, *gparent;
- while ((parent = rb_parent(node)) && rb_is_red(parent))
- {
+ while (true) {
+ /*
+* Loop invariant: node is red
+*
+* If there is a black parent, we are done.
+* Otherwise, take some corrective action as we don't
+* want a red root or two consecutive red nodes.
+*/
+ parent = rb_parent(node);
+ if (!parent) {
+ rb_set_black(node);
+ break;
+ } else if (rb_is_black(parent))
+ break;
+
gparent = rb_parent(parent);
if (parent == gparent->rb_left)
@@ -142,8 +155,6 @@ void rb_insert_color(struct rb_node *node, struct rb_root
*root)
break;
}
}
-
- rb_set_black(root->rb_node);
}
EXPORT_SYMBOL(rb_insert_color);
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/12] rbtree: low level optimizations in rb_insert_color()
- Use the newly introduced rb_set_parent_color() function to flip the color
of nodes whose parent is already known.
- Optimize rb_parent() when the node is known to be red - there is no need
to mask out the color in that case.
- Flipping gparent's color to red requires us to fetch its rb_parent_color
field, so we can reuse it as the parent value for the next loop iteration.
- Do not use __rb_rotate_left() and __rb_rotate_right() to handle tree
rotations: we already have pointers to all relevant nodes, and know their
colors (either because we want to adjust it, or because we've tested it,
or we can deduce it as black due to the node proximity to a known red node).
So we can generate more efficient code by making use of the node pointers
we already have, and setting both the parent and color attributes for
nodes all at once. Also in Case 2, some node attributes don't have to
be set because we know another tree rotation (Case 3) will always follow
and override them.
Signed-off-by: Michel Lespinasse
---
lib/rbtree.c | 166 +
1 files changed, 131 insertions(+), 35 deletions(-)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index d0be5fc..41cf19b 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -23,6 +23,25 @@
#include
#include
+/*
+ * red-black trees properties: http://en.wikipedia.org/wiki/Rbtree
+ *
+ * 1) A node is either red or black
+ * 2) The root is black
+ * 3) All leaves (NULL) are black
+ * 4) Both children of every red node are black
+ * 5) Every simple path from root to leaves contains the same number
+ * of black nodes.
+ *
+ * 4 and 5 give the O(log n) guarantee, since 4 implies you cannot have two
+ * consecutive red nodes in a path and every red node is therefore followed by
+ * a black. So if B is the number of black nodes on every simple path (as per
+ * 5), then the longest possible path due to 4 is 2B.
+ *
+ * We shall indicate color with case, where black nodes are uppercase and red
+ * nodes will be lowercase.
+ */
+
#defineRB_RED 0
#defineRB_BLACK1
@@ -41,6 +60,17 @@ static inline void rb_set_color(struct rb_node *rb, int
color)
rb->__rb_parent_color = (rb->__rb_parent_color & ~1) | color;
}
+static inline void rb_set_parent_color(struct rb_node *rb,
+ struct rb_node *p, int color)
+{
+ rb->__rb_parent_color = (unsigned long)p | color;
+}
+
+static inline struct rb_node *rb_red_parent(struct rb_node *red)
+{
+ return (struct rb_node *)red->__rb_parent_color;
+}
+
static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
{
struct rb_node *right = node->rb_right;
@@ -87,9 +117,30 @@ static void __rb_rotate_right(struct rb_node *node, struct
rb_root *root)
rb_set_parent(node, left);
}
+/*
+ * Helper function for rotations:
+ * - old's parent and color get assigned to new
+ * - old gets assigned new as a parent and 'color' as a color.
+ */
+static inline void
+__rb_rotate_set_parents(struct rb_node *old, struct rb_node *new,
+ struct rb_root *root, int color)
+{
+ struct rb_node *parent = rb_parent(old);
+ new->__rb_parent_color = old->__rb_parent_color;
+ rb_set_parent_color(old, new, color);
+ if (parent) {
+ if (parent->rb_left == old)
+ parent->rb_left = new;
+ else
+ parent->rb_right = new;
+ } else
+ root->rb_node = new;
+}
+
void rb_insert_color(struct rb_node *node, struct rb_root *root)
{
- struct rb_node *parent, *gparent;
+ struct rb_node *parent = rb_red_parent(node), *gparent, *tmp;
while (true) {
/*
@@ -99,59 +150,104 @@ void rb_insert_color(struct rb_node *node, struct rb_root
*root)
* Otherwise, take some corrective action as we don't
* want a red root or two consecutive red nodes.
*/
- parent = rb_parent(node);
if (!parent) {
- rb_set_black(node);
+ rb_set_parent_color(node, NULL, RB_BLACK);
break;
} else if (rb_is_black(parent))
break;
- gparent = rb_parent(parent);
-
- if (parent == gparent->rb_left)
- {
- {
- register struct rb_node *uncle =
gparent->rb_right;
- if (uncle && rb_is_red(uncle))
- {
- rb_set_black(uncle);
- rb_set_black(parent);
- rb_set_red(gparent);
- node = gparent;
- continue;
- }
+
[PATCH v2 09/12] rbtree: adjust node color in __rb_erase_color() only when necessary
In __rb_erase_color(), we were always setting a node to black after
exiting the main loop. And in one case, after fixing up the tree to
satisfy all rbtree invariants, we were setting the current node to root
just to guarantee a loop exit, at which point the root would be set to
black. However this is not necessary, as the root of an rbtree is already
known to be black. The only case where the color flip is required is when
we exit the loop due to the current node being red, and it's easiest to
just do the flip at that point instead of doing it after the loop.
Signed-off-by: Michel Lespinasse
---
lib/rbtree.c | 28 +---
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index 41cf19b..baf7c83 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -259,10 +259,22 @@ static void __rb_erase_color(struct rb_node *node, struct
rb_node *parent,
{
struct rb_node *other;
- while ((!node || rb_is_black(node)) && node != root->rb_node)
- {
- if (parent->rb_left == node)
- {
+ while (true) {
+ /*
+* Loop invariant: all leaf paths going through node have a
+* black node count that is 1 lower than other leaf paths.
+*
+* If node is red, we can flip it to black to adjust.
+* If node is the root, all leaf paths go through it.
+* Otherwise, we need to adjust the tree through color flips
+* and tree rotations as per one of the 4 cases below.
+*/
+ if (node && rb_is_red(node)) {
+ rb_set_black(node);
+ break;
+ } else if (!parent) {
+ break;
+ } else if (parent->rb_left == node) {
other = parent->rb_right;
if (rb_is_red(other))
{
@@ -291,12 +303,9 @@ static void __rb_erase_color(struct rb_node *node, struct
rb_node *parent,
rb_set_black(parent);
rb_set_black(other->rb_right);
__rb_rotate_left(parent, root);
- node = root->rb_node;
break;
}
- }
- else
- {
+ } else {
other = parent->rb_left;
if (rb_is_red(other))
{
@@ -325,13 +334,10 @@ static void __rb_erase_color(struct rb_node *node, struct
rb_node *parent,
rb_set_black(parent);
rb_set_black(other->rb_left);
__rb_rotate_right(parent, root);
- node = root->rb_node;
break;
}
}
}
- if (node)
- rb_set_black(node);
}
void rb_erase(struct rb_node *node, struct rb_root *root)
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/12] rbtree: low level optimizations in __rb_erase_color()
In __rb_erase_color(), we often already have pointers to the nodes
being rotated and/or know what their colors must be, so we can
generate more efficient code than the generic __rb_rotate_left()
and __rb_rotate_right() functions.
Also when the current node is red or when flipping the sibling's color,
the parent is already known so we can use the more efficient
rb_set_parent_color() function to set the desired color.
Signed-off-by: Michel Lespinasse
---
lib/rbtree.c | 208 --
1 files changed, 115 insertions(+), 93 deletions(-)
diff --git a/lib/rbtree.c b/lib/rbtree.c
index eb823a3..a38e473 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -39,7 +39,8 @@
* 5), then the longest possible path due to 4 is 2B.
*
* We shall indicate color with case, where black nodes are uppercase and red
- * nodes will be lowercase.
+ * nodes will be lowercase. Unknown color nodes shall be drawn as red within
+ * parentheses and have some accompanying text comment.
*/
#defineRB_RED 0
@@ -48,17 +49,11 @@
#define rb_color(r) ((r)->__rb_parent_color & 1)
#define rb_is_red(r) (!rb_color(r))
#define rb_is_black(r) rb_color(r)
-#define rb_set_red(r) do { (r)->__rb_parent_color &= ~1; } while (0)
-#define rb_set_black(r) do { (r)->__rb_parent_color |= 1; } while (0)
static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
{
rb->__rb_parent_color = rb_color(rb) | (unsigned long)p;
}
-static inline void rb_set_color(struct rb_node *rb, int color)
-{
- rb->__rb_parent_color = (rb->__rb_parent_color & ~1) | color;
-}
static inline void rb_set_parent_color(struct rb_node *rb,
struct rb_node *p, int color)
@@ -71,52 +66,6 @@ static inline struct rb_node *rb_red_parent(struct rb_node
*red)
return (struct rb_node *)red->__rb_parent_color;
}
-static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
-{
- struct rb_node *right = node->rb_right;
- struct rb_node *parent = rb_parent(node);
-
- if ((node->rb_right = right->rb_left))
- rb_set_parent(right->rb_left, node);
- right->rb_left = node;
-
- rb_set_parent(right, parent);
-
- if (parent)
- {
- if (node == parent->rb_left)
- parent->rb_left = right;
- else
- parent->rb_right = right;
- }
- else
- root->rb_node = right;
- rb_set_parent(node, right);
-}
-
-static void __rb_rotate_right(struct rb_node *node, struct rb_root *root)
-{
- struct rb_node *left = node->rb_left;
- struct rb_node *parent = rb_parent(node);
-
- if ((node->rb_left = left->rb_right))
- rb_set_parent(left->rb_right, node);
- left->rb_right = node;
-
- rb_set_parent(left, parent);
-
- if (parent)
- {
- if (node == parent->rb_right)
- parent->rb_right = left;
- else
- parent->rb_left = left;
- }
- else
- root->rb_node = left;
- rb_set_parent(node, left);
-}
-
/*
* Helper function for rotations:
* - old's parent and color get assigned to new
@@ -257,7 +206,7 @@ EXPORT_SYMBOL(rb_insert_color);
static void __rb_erase_color(struct rb_node *node, struct rb_node *parent,
struct rb_root *root)
{
- struct rb_node *other;
+ struct rb_node *sibling, *tmp1, *tmp2;
while (true) {
/*
@@ -270,63 +219,136 @@ static void __rb_erase_color(struct rb_node *node,
struct rb_node *parent,
* and tree rotations as per one of the 4 cases below.
*/
if (node && rb_is_red(node)) {
- rb_set_black(node);
+ rb_set_parent_color(node, parent, RB_BLACK);
break;
} else if (!parent) {
break;
} else if (parent->rb_left == node) {
- other = parent->rb_right;
- if (rb_is_red(other))
- {
- rb_set_black(other);
- rb_set_red(parent);
- __rb_rotate_left(parent, root);
- other = parent->rb_right;
+ sibling = parent->rb_right;
+ if (rb_is_red(sibling)) {
+ /*
+* Case 1 - left rotate at parent
+*
+* P S
+*/ \ / \
+* N s-->p Sr
+* / \ / \
+* Sl Sr N Sl
+
[PATCH v2 05/12] rbtree: performance and correctness test
This small module helps measure the performance of rbtree insert and erase.
Additionally, we run a few correctness tests to check that the rbtrees have
all desired properties:
- contains the right number of nodes in the order desired,
- never two consecutive red nodes on any path,
- all paths to leaf nodes have the same number of black nodes,
- root node is black
Signed-off-by: Michel Lespinasse
---
Makefile|2 +-
lib/Kconfig.debug |1 +
tests/Kconfig | 18 +++
tests/Makefile |1 +
tests/rbtree_test.c | 135 +++
5 files changed, 156 insertions(+), 1 deletions(-)
create mode 100644 tests/Kconfig
create mode 100644 tests/Makefile
create mode 100644 tests/rbtree_test.c
diff --git a/Makefile b/Makefile
index a687963..7bef085 100644
--- a/Makefile
+++ b/Makefile
@@ -708,7 +708,7 @@ export mod_strip_cmd
ifeq ($(KBUILD_EXTMOD),)
-core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
+core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ tests/
vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
$(core-y) $(core-m) $(drivers-y) $(drivers-m) \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 6777153..b148fa1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1144,6 +1144,7 @@ config LATENCYTOP
source mm/Kconfig.debug
source kernel/trace/Kconfig
+source tests/Kconfig
config PROVIDE_OHCI1394_DMA_INIT
bool "Remote debugging over FireWire early on boot"
diff --git a/tests/Kconfig b/tests/Kconfig
new file mode 100644
index 000..ceca7ba
--- /dev/null
+++ b/tests/Kconfig
@@ -0,0 +1,18 @@
+menuconfig BENCHMARKS
+ bool "In kernel benchmarks"
+ def_bool n
+ help
+ Includes in kernel benchmark modules in the build. These modules can
+ be loaded later to trigger benchmarking kernel subsystems.
+ Output will be generated in the system log.
+
+if BENCHMARKS
+
+config BENCHMARK_RBTREE
+ tristate "Red Black Tree Benchmark"
+ depends on m
+ default m
+ help
+ A benchmark measuring the performance of the rbtree library.
+
+endif # BENCHMARKS
diff --git a/tests/Makefile b/tests/Makefile
new file mode 100644
index 000..440b77c
--- /dev/null
+++ b/tests/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_BENCHMARK_RBTREE) += rbtree_test.o
diff --git a/tests/rbtree_test.c b/tests/rbtree_test.c
new file mode 100644
index 000..4c6d250
--- /dev/null
+++ b/tests/rbtree_test.c
@@ -0,0 +1,135 @@
+#include
+#include
+#include
+#include
+
+#define NODES 100
+#define PERF_LOOPS 10
+#define CHECK_LOOPS 100
+
+struct test_node {
+ struct rb_node rb;
+ u32 key;
+};
+
+static struct rb_root root = RB_ROOT;
+static struct test_node nodes[NODES];
+
+static struct rnd_state rnd;
+
+static void insert(struct test_node *node, struct rb_root *root)
+{
+ struct rb_node **new = &root->rb_node, *parent = NULL;
+
+ while (*new) {
+ parent = *new;
+ if (node->key < rb_entry(parent, struct test_node, rb)->key)
+ new = &parent->rb_left;
+ else
+ new = &parent->rb_right;
+ }
+
+ rb_link_node(&node->rb, parent, new);
+ rb_insert_color(&node->rb, root);
+}
+
+static inline void erase(struct test_node *node, struct rb_root *root)
+{
+ rb_erase(&node->rb, root);
+}
+
+static void init(void)
+{
+ int i;
+ for (i = 0; i < NODES; i++)
+ nodes[i].key = prandom32(&rnd);
+}
+
+static bool is_red(struct rb_node *rb)
+{
+ return !(rb->__rb_parent_color & 1);
+}
+
+static int black_path_count(struct rb_node *rb)
+{
+ int count;
+ for (count = 0; rb; rb = rb_parent(rb))
+ count += !is_red(rb);
+ return count;
+}
+
+static void check(int nr_nodes)
+{
+ struct rb_node *rb;
+ int count = 0;
+ int blacks;
+ u32 prev_key = 0;
+
+ for (rb = rb_first(&root); rb; rb = rb_next(rb)) {
+ struct test_node *node = rb_entry(rb, struct test_node, rb);
+ WARN_ON_ONCE(node->key < prev_key);
+ WARN_ON_ONCE(is_red(rb) &&
+(!rb_parent(rb) || is_red(rb_parent(rb;
+ if (!count)
+ blacks = black_path_count(rb);
+ else
+ WARN_ON_ONCE((!rb->rb_left || !rb->rb_right) &&
+blacks != black_path_count(rb));
+ prev_key = node->key;
+ count++;
+ }
+ WARN_ON_ONCE(count != nr_nodes);
+}
+
+static int rbtree_test_init(void)
+{
+ int i, j;
+ cycles_t time1, time2, time;
+
+ printk(KERN_ALERT "rbtree testing");
+
+ prandom32_seed(&rnd, 3141592653589793238);
+ init();
+
+ time1 = get_cycles();
+
+ for (i = 0; i < PERF_LOOPS; i++) {
+ for (j
[PATCH v2 04/12] rbtree: move some implementation details from rbtree.h to rbtree.c
rbtree users must use the documented APIs to manipulate the tree
structure. Low-level helpers to manipulate node colors and parenthood
are not part of that API, so move them to lib/rbtree.c
Signed-off-by: Michel Lespinasse
---
include/linux/rbtree.h | 34 +-
lib/rbtree.c | 20 +++-
2 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index 2049087..bf836a2 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -32,37 +32,19 @@
#include
#include
-struct rb_node
-{
- unsigned long rb_parent_color;
-#defineRB_RED 0
-#defineRB_BLACK1
+struct rb_node {
+ unsigned long __rb_parent_color;
struct rb_node *rb_right;
struct rb_node *rb_left;
} __attribute__((aligned(sizeof(long;
/* The alignment might seem pointless, but allegedly CRIS needs it */
-struct rb_root
-{
+struct rb_root {
struct rb_node *rb_node;
};
-#define rb_parent(r) ((struct rb_node *)((r)->rb_parent_color & ~3))
-#define rb_color(r) ((r)->rb_parent_color & 1)
-#define rb_is_red(r) (!rb_color(r))
-#define rb_is_black(r) rb_color(r)
-#define rb_set_red(r) do { (r)->rb_parent_color &= ~1; } while (0)
-#define rb_set_black(r) do { (r)->rb_parent_color |= 1; } while (0)
-
-static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
-{
- rb->rb_parent_color = (rb->rb_parent_color & 3) | (unsigned long)p;
-}
-static inline void rb_set_color(struct rb_node *rb, int color)
-{
- rb->rb_parent_color = (rb->rb_parent_color & ~1) | color;
-}
+#define rb_parent(r) ((struct rb_node *)((r)->__rb_parent_color & ~3))
#define RB_ROOT(struct rb_root) { NULL, }
#definerb_entry(ptr, type, member) container_of(ptr, type, member)
@@ -70,8 +52,10 @@ static inline void rb_set_color(struct rb_node *rb, int
color)
#define RB_EMPTY_ROOT(root) ((root)->rb_node == NULL)
/* 'empty' nodes are nodes that are known not to be inserted in an rbree */
-#define RB_EMPTY_NODE(node) ((node)->rb_parent_color == (unsigned long)(node))
-#define RB_CLEAR_NODE(node) ((node)->rb_parent_color = (unsigned long)(node))
+#define RB_EMPTY_NODE(node) \
+ ((node)->__rb_parent_color == (unsigned long)(node))
+#define RB_CLEAR_NODE(node) \
+ ((node)->__rb_parent_color = (unsigned long)(node))
extern void rb_insert_color(struct rb_node *, struct rb_root *);
@@ -98,7 +82,7 @@ extern void rb_replace_node(struct rb_node *victim, struct
rb_node *new,
static inline void rb_link_node(struct rb_node * node, struct rb_node * parent,
struct rb_node ** rb_link)
{
- node->rb_parent_color = (unsigned long )parent;
+ node->__rb_parent_color = (unsigned long)parent;
node->rb_left = node->rb_right = NULL;
*rb_link = node;
diff --git a/lib/rbtree.c b/lib/rbtree.c
index fe43c8c..ccada9a 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -23,6 +23,24 @@
#include
#include
+#defineRB_RED 0
+#defineRB_BLACK1
+
+#define rb_color(r) ((r)->__rb_parent_color & 1)
+#define rb_is_red(r) (!rb_color(r))
+#define rb_is_black(r) rb_color(r)
+#define rb_set_red(r) do { (r)->__rb_parent_color &= ~1; } while (0)
+#define rb_set_black(r) do { (r)->__rb_parent_color |= 1; } while (0)
+
+static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
+{
+ rb->__rb_parent_color = rb_color(rb) | (unsigned long)p;
+}
+static inline void rb_set_color(struct rb_node *rb, int color)
+{
+ rb->__rb_parent_color = (rb->__rb_parent_color & ~1) | color;
+}
+
static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
{
struct rb_node *right = node->rb_right;
@@ -255,7 +273,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
rb_set_parent(old->rb_right, node);
}
- node->rb_parent_color = old->rb_parent_color;
+ node->__rb_parent_color = old->__rb_parent_color;
node->rb_left = old->rb_left;
rb_set_parent(old->rb_left, node);
--
1.7.7.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/
