s390/ap_bus: Convert timers to use timer_setup()
Subsystems (2)
PATCH 1/1 s390/ap_bus: Convert timers to use timer_setup()
In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly.
--- drivers/s390/crypto/ap_bus.c | 10 +++++----- drivers/s390/crypto/ap_bus.h | 2 +- drivers/s390/crypto/ap_queue.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)
drivers/s390/crypto/ap_bus.c +5 -5
@@ -362,13 +362,13 @@ void ap_wait(enum ap_wait wait)/** * ap_request_timeout(): Handling of request timeouts -* @data: Holds the AP device. +* @t: timer making this callback * * Handles request timeouts. */ -void ap_request_timeout (unsigned long data) +void ap_request_timeout (struct timer_list *t) { -struct ap_queue *aq = (struct ap_queue *) data; +struct ap_queue *aq =from_timer (aq, t, timeout);if (ap_suspend_flag)return ;
@@ -1147,7 +1147,7 @@ static void ap_scan_bus(struct work_struct *unused)mod_timer (&ap_config_timer, jiffies + ap_config_time *HZ ); } -static void ap_config_timeout (unsigned long ptr) +static void ap_config_timeout (struct timer_list *unused) {if (ap_suspend_flag)return ;
@@ -1250,7 +1250,7 @@ int __init ap_module_init(void) goto out_bus;/* Setup the AP bus rescan timer. */ -setup_timer (&ap_config_timer, ap_config_timeout,0 ); +timer_setup (&ap_config_timer, ap_config_timeout,0 );/* * Setup the high resultion poll timer.
drivers/s390/crypto/ap_bus.h +1 -1
@@ -241,7 +241,7 @@ void ap_flush_queue(struct ap_queue *aq);void *ap_airq_ptr (void );void ap_wait (enum ap_wait wait); -void ap_request_timeout (unsigned long data); +void ap_request_timeout (struct timer_list *t);void ap_bus_force_rescan (void );void ap_queue_init_reply (struct ap_queue *aq,struct ap_message *ap_msg);
drivers/s390/crypto/ap_queue.c +1 -1
@@ -635,7 +635,7 @@ struct ap_queue *ap_queue_create(ap_qid_t qid, int device_type)spin_lock_init (&aq->lock);INIT_LIST_HEAD (&aq->pendingq);INIT_LIST_HEAD (&aq->requestq); -setup_timer (&aq->timeout, ap_request_timeout, (unsigned long ) aq); +timer_setup (&aq->timeout, ap_request_timeout,0 );return aq; }
Signature · 6 lines
2.7.4 -- Kees Cook Pixel Security
Quoted 9 lines · On Wed, 25 Oct 2017 03:27:37 -0700 Kees Cook <[email protected]> wrote:
In preparation for unconditionally passing the struct
timer_listpointer to all timer callbacks, switch to using the newtimer_setup()andfrom_timer()to pass the timer pointer explicitly.Cc Harald Freudenberger <[email protected]>Cc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Signed-off-by Kees Cook <[email protected]>
Quoted 5 lines
--- drivers/s390/crypto/ap_bus.c | 10 +++++----- drivers/s390/crypto/ap_bus.h | 2 +- drivers/s390/crypto/ap_queue.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)
Parked for the second part of the s390 updates for the next merge window. Thanks.
Signature · 4 lines
blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Quoted 18 lines · Martin Schwidefsky
Quoted 9 lines · On Wed, 25 Oct 2017 03:27:37 -0700 Kees Cook <[email protected]> wrote:
In preparation for unconditionally passing the struct
timer_listpointer to all timer callbacks, switch to using the newtimer_setup()andfrom_timer()to pass the timer pointer explicitly.Cc Harald Freudenberger <[email protected]>Cc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Signed-off-by Kees Cook <[email protected]>Quoted 5 lines
--- drivers/s390/crypto/ap_bus.c | 10 +++++----- drivers/s390/crypto/ap_bus.h | 2 +- drivers/s390/crypto/ap_queue.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)
Quoted 2 lines
Parked for the second part of the s390 updates for the next merge window. Thanks.
Thanks for getting these staged. I just wanted to check with you, since I don't see these in -next anywhere yet:
s390: qdio: Convert timers to use timer_setup()
s390/sclp: Convert timers to use timer_setup()
s390/cio: Convert timers to use timer_setup()
s390/scsi: Convert timers to use timer_setup()
s390/ap_bus: Convert timers to use timer_setup()
Are all of these expected to land for -rc1? (Would it help to carry them in the timer tree?) I've got tree-wide changes ready to go once all these conversions have landed.
Thanks!
-Kees
Signature · 2 lines
Kees Cook Pixel Security
Quoted 32 lines · On Thu, 2 Nov 2017 16:36:53 -0700 Kees Cook <[email protected]> wrote:
Quoted 18 lines · Martin Schwidefsky
Quoted 9 lines · On Wed, 25 Oct 2017 03:27:37 -0700 Kees Cook <[email protected]> wrote:
In preparation for unconditionally passing the struct
timer_listpointer to all timer callbacks, switch to using the newtimer_setup()andfrom_timer()to pass the timer pointer explicitly.Cc Harald Freudenberger <[email protected]>Cc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Signed-off-by Kees Cook <[email protected]>Quoted 5 lines
--- drivers/s390/crypto/ap_bus.c | 10 +++++----- drivers/s390/crypto/ap_bus.h | 2 +- drivers/s390/crypto/ap_queue.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)Quoted 2 lines
Parked for the second part of the s390 updates for the next merge window. Thanks.
Thanks for getting these staged. I just wanted to check with you, since I don't see these in -next anywhere yet:
s390: qdio: Convert timers to use
timer_setup()
s390/sclp: Convert timers to usetimer_setup()
s390/cio: Convert timers to usetimer_setup()
s390/scsi: Convert timers to usetimer_setup()
s390/ap_bus: Convert timers to usetimer_setup()
Quoted 3 lines
Are all of these expected to land for -rc1? (Would it help to carry them in the timer tree?) I've got tree-wide changes ready to go once all these conversions have landed.
These patches are parked on a private branches. The features branch on s390/linux is the one that is used for -next AND for the upstream merge. And since I do not want to rebase that branch the timer_setup patches are not in -next as well.
Four of you patches are safe with me, the s390/scsi patch is in Steffens patch queue. All good I would say.
Signature · 4 lines
blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Quoted 39 lines · Martin Schwidefsky
Quoted 32 lines · On Thu, 2 Nov 2017 16:36:53 -0700 Kees Cook <[email protected]> wrote:
Quoted 18 lines · Martin Schwidefsky
Quoted 9 lines · On Wed, 25 Oct 2017 03:27:37 -0700 Kees Cook <[email protected]> wrote:
In preparation for unconditionally passing the struct
timer_listpointer to all timer callbacks, switch to using the newtimer_setup()andfrom_timer()to pass the timer pointer explicitly.Cc Harald Freudenberger <[email protected]>Cc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Signed-off-by Kees Cook <[email protected]>Quoted 5 lines
--- drivers/s390/crypto/ap_bus.c | 10 +++++----- drivers/s390/crypto/ap_bus.h | 2 +- drivers/s390/crypto/ap_queue.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)Quoted 2 lines
Parked for the second part of the s390 updates for the next merge window. Thanks.
Thanks for getting these staged. I just wanted to check with you, since I don't see these in -next anywhere yet:
s390: qdio: Convert timers to use
timer_setup()
s390/sclp: Convert timers to usetimer_setup()
s390/cio: Convert timers to usetimer_setup()
s390/scsi: Convert timers to usetimer_setup()
s390/ap_bus: Convert timers to usetimer_setup()Quoted 3 lines
Are all of these expected to land for -rc1? (Would it help to carry them in the timer tree?) I've got tree-wide changes ready to go once all these conversions have landed.
Quoted 7 lines
These patches are parked on a private branches. The features branch on s390/linux is the one that is used for -next AND for the upstream merge. And since I do not want to rebase that branch the
timer_setuppatches are not in -next as well.Four of you patches are safe with me, the s390/scsi patch is in Steffens patch queue. All good I would say.
Great, thanks very much for double-check! :)
-Kees
Signature · 2 lines
Kees Cook Pixel Security
Quoted 39 lines · Martin Schwidefsky
Quoted 32 lines · On Thu, 2 Nov 2017 16:36:53 -0700 Kees Cook <[email protected]> wrote:
Quoted 18 lines · Martin Schwidefsky
Quoted 9 lines · On Wed, 25 Oct 2017 03:27:37 -0700 Kees Cook <[email protected]> wrote:
In preparation for unconditionally passing the struct
timer_listpointer to all timer callbacks, switch to using the newtimer_setup()andfrom_timer()to pass the timer pointer explicitly.Cc Harald Freudenberger <[email protected]>Cc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Signed-off-by Kees Cook <[email protected]>Quoted 5 lines
--- drivers/s390/crypto/ap_bus.c | 10 +++++----- drivers/s390/crypto/ap_bus.h | 2 +- drivers/s390/crypto/ap_queue.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)Quoted 2 lines
Parked for the second part of the s390 updates for the next merge window. Thanks.
Thanks for getting these staged. I just wanted to check with you, since I don't see these in -next anywhere yet:
s390: qdio: Convert timers to use
timer_setup()
s390/sclp: Convert timers to usetimer_setup()
s390/cio: Convert timers to usetimer_setup()
s390/scsi: Convert timers to usetimer_setup()
s390/ap_bus: Convert timers to usetimer_setup()Quoted 3 lines
Are all of these expected to land for -rc1? (Would it help to carry them in the timer tree?) I've got tree-wide changes ready to go once all these conversions have landed.
Quoted 7 lines
These patches are parked on a private branches. The features branch on s390/linux is the one that is used for -next AND for the upstream merge. And since I do not want to rebase that branch the
timer_setuppatches are not in -next as well.Four of you patches are safe with me, the s390/scsi patch is in Steffens patch queue. All good I would say.
Hi,
I saw s390 get merged for -rc1, but none of these timer_setup() conversions were included. Given the possible short merge window, what's the state of these? I can't do the bulk API changes at the end of -rc1 without the s390 timer patches. Anything I can help with?
Thanks!
-Kees
Signature · 2 lines
Kees Cook Pixel Security
Quoted 49 lines · On Wed, 15 Nov 2017 23:58:44 -0800 Kees Cook <[email protected]> wrote:
Quoted 39 lines · Martin Schwidefsky
Quoted 32 lines · On Thu, 2 Nov 2017 16:36:53 -0700 Kees Cook <[email protected]> wrote:
Quoted 18 lines · Martin Schwidefsky
Quoted 9 lines · On Wed, 25 Oct 2017 03:27:37 -0700 Kees Cook <[email protected]> wrote:
In preparation for unconditionally passing the struct
timer_listpointer to all timer callbacks, switch to using the newtimer_setup()andfrom_timer()to pass the timer pointer explicitly.Cc Harald Freudenberger <[email protected]>Cc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Signed-off-by Kees Cook <[email protected]>Quoted 5 lines
--- drivers/s390/crypto/ap_bus.c | 10 +++++----- drivers/s390/crypto/ap_bus.h | 2 +- drivers/s390/crypto/ap_queue.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)Quoted 2 lines
Parked for the second part of the s390 updates for the next merge window. Thanks.
Thanks for getting these staged. I just wanted to check with you, since I don't see these in -next anywhere yet:
s390: qdio: Convert timers to use
timer_setup()
s390/sclp: Convert timers to usetimer_setup()
s390/cio: Convert timers to usetimer_setup()
s390/scsi: Convert timers to usetimer_setup()
s390/ap_bus: Convert timers to usetimer_setup()Quoted 3 lines
Are all of these expected to land for -rc1? (Would it help to carry them in the timer tree?) I've got tree-wide changes ready to go once all these conversions have landed.
Quoted 7 lines
These patches are parked on a private branches. The features branch on s390/linux is the one that is used for -next AND for the upstream merge. And since I do not want to rebase that branch the
timer_setuppatches are not in -next as well.Four of you patches are safe with me, the s390/scsi patch is in Steffens patch queue. All good I would say.
Quoted 6 lines
Hi,
I saw s390 get merged for -rc1, but none of these
timer_setup()conversions were included. Given the possible short merge window, what's the state of these? I can't do the bulk API changes at the end of -rc1 without the s390 timer patches. Anything I can help with?
The remaining timer_setup changes are on the features branch of s390/linux, I plan to send a please-pull request be the end of the week.
Signature · 4 lines
blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Quoted 54 lines · Martin Schwidefsky
Quoted 51 lines · On Wed, 15 Nov 2017 23:58:44 -0800 Kees Cook <[email protected]> wrote:
Quoted 39 lines · Martin Schwidefsky
Quoted 32 lines · On Thu, 2 Nov 2017 16:36:53 -0700 Kees Cook <[email protected]> wrote:
Quoted 18 lines · Martin Schwidefsky
Quoted 9 lines · On Wed, 25 Oct 2017 03:27:37 -0700 Kees Cook <[email protected]> wrote:
In preparation for unconditionally passing the struct
timer_listpointer to all timer callbacks, switch to using the newtimer_setup()andfrom_timer()to pass the timer pointer explicitly.Cc Harald Freudenberger <[email protected]>Cc Martin Schwidefsky <[email protected]>Cc Heiko Carstens <[email protected]>Signed-off-by Kees Cook <[email protected]>Quoted 5 lines
--- drivers/s390/crypto/ap_bus.c | 10 +++++----- drivers/s390/crypto/ap_bus.h | 2 +- drivers/s390/crypto/ap_queue.c | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)Quoted 2 lines
Parked for the second part of the s390 updates for the next merge window. Thanks.
Thanks for getting these staged. I just wanted to check with you, since I don't see these in -next anywhere yet:
s390: qdio: Convert timers to use
timer_setup()
s390/sclp: Convert timers to usetimer_setup()
s390/cio: Convert timers to usetimer_setup()
s390/scsi: Convert timers to usetimer_setup()
s390/ap_bus: Convert timers to usetimer_setup()Quoted 3 lines
Are all of these expected to land for -rc1? (Would it help to carry them in the timer tree?) I've got tree-wide changes ready to go once all these conversions have landed.
Quoted 7 lines
These patches are parked on a private branches. The features branch on s390/linux is the one that is used for -next AND for the upstream merge. And since I do not want to rebase that branch the
timer_setuppatches are not in -next as well.Four of you patches are safe with me, the s390/scsi patch is in Steffens patch queue. All good I would say.
Hi,
Quoted 7 lines
Quoted 4 lines
I saw s390 get merged for -rc1, but none of these
timer_setup()conversions were included. Given the possible short merge window, what's the state of these? I can't do the bulk API changes at the end of -rc1 without the s390 timer patches. Anything I can help with?The remaining
timer_setupchanges are on the features branch of s390/linux, I plan to send a please-pull request be the end of the week.
Okay, thanks! Sorry for all my nail-biting. :)
-Kees
Signature · 2 lines
Kees Cook Pixel Security