We could create a work_struct for each event, which would be fine.
Yes, that would be the normal way to do it. You initialize the work
structures from the initial probe function to have the right
callbacks, and then you just queue the right one when you need to
defer an event.
How many differ
On Monday 19 October 2015 15:55:47 John Garry wrote:
> > Do you mean these members?
> >
> >> + wq->event = PHYUP;
> >> + wq->hisi_hba = hisi_hba;
> >> + wq->phy_no = phy_no;
> >
> Yes, these are the members I was referring to. However there is also an
> element "data" in hisi_sas
I'd have to review more closely, but I think that's fine, as this
is how most work queues are used: you can queue the same function
multiple times, and it's guaranteed to run at least once after
the last queue, so if you queue it while it's already running,
it will be called again, otherwise it wo
On Monday 19 October 2015 15:11:47 John Garry wrote:
> On 16/10/2015 14:36, Arnd Bergmann wrote:
> > On Friday 16 October 2015 14:29:55 John Garry wrote:
> >>
> >> It could be considered.
> >>
> >> A potential issue I see is with hisi_sas_control_phy() for
> >> PHY_FUNC_HARD_RESET: this allocates a
On 16/10/2015 14:36, Arnd Bergmann wrote:
On Friday 16 October 2015 14:29:55 John Garry wrote:
It could be considered.
A potential issue I see is with hisi_sas_control_phy() for
PHY_FUNC_HARD_RESET: this allocates a hisi_sas_wq struct and processes
the reset in the queue work. When we re-enabl
On Friday 16 October 2015 14:29:55 John Garry wrote:
>
> It could be considered.
>
> A potential issue I see is with hisi_sas_control_phy() for
> PHY_FUNC_HARD_RESET: this allocates a hisi_sas_wq struct and processes
> the reset in the queue work. When we re-enable the phy for the reset,
> the
On 16/10/2015 13:55, Arnd Bergmann wrote:
On Monday 12 October 2015 23:20:25 John Garry wrote:
@@ -804,6 +818,16 @@ static irqreturn_t int_phyup_v1_hw(int irq_no, void *p)
phy->identify.target_port_protocols =
SAS_PROTOCOL_SMP;
+ wq = kmalloc(size
On Monday 12 October 2015 23:20:25 John Garry wrote:
> @@ -804,6 +818,16 @@ static irqreturn_t int_phyup_v1_hw(int irq_no, void *p)
> phy->identify.target_port_protocols =
> SAS_PROTOCOL_SMP;
>
> + wq = kmalloc(sizeof(*wq), GFP_ATOMIC);
> + if (
Hi Julian,
Oops, this is awkward.. I'll check it, thank you for the reminder!
Thanks,
Fengguang
On Tue, Oct 13, 2015 at 11:27:05AM +1100, Julian Calaby wrote:
> Hi kbuild test robot people,
>
> On Tue, Oct 13, 2015 at 9:03 AM, kbuild test robot wrote:
> > Hi John,
> >
> > [auto build test WARN
Hi kbuild test robot people,
On Tue, Oct 13, 2015 at 9:03 AM, kbuild test robot wrote:
> Hi John,
>
> [auto build test WARNING on scsi/for-next -- if it's inappropriate base,
> please suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commits/John
Hi John,
[auto build test WARNING on scsi/for-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/John-Garry/HiSilicon-SAS-driver/20151012-231929
reproduce:
# apt-get install sparse
make
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas.h | 1 +
drivers/scsi/hisi_sas/hisi_sas_main.c | 55 ++
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 24 +++
3 files changed, 80 insertions(+)
diff --git a/drivers/scsi/hisi_sas/hisi_sas.
12 matches
Mail list logo
