From: John Garry <john.garry@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: <James.Bottomley@hansenpartnership.com>,
<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linuxarm@huawei.com>, <zhangfei.gao@linaro.org>,
<linux-scsi@vger.kernel.org>, <xuwei5@hisilicon.com>,
<john.garry2@mail.dcu.ie>, <hare@suse.de>
Subject: Re: [PATCH 13/25] scsi: hisi_sas: add path from phyup irq to SAS framework
Date: Mon, 19 Oct 2015 15:55:47 +0100 [thread overview]
Message-ID: <56250473.9090700@huawei.com> (raw)
In-Reply-To: <4269975.xfCo9ut8KK@wuerfel>
>>> 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 won't.
>>>
>> In the scenario I described the issue is not that the second call to
>> queue the work function is lost. The problem is that when we setup the
>> second call we may overwrite elements of the phy's hisi_sas_wq struct
>> which may be still being referenced in the work function for the first call.
>
> 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_wq. This is used in control phy as follows:
int hisi_sas_control_phy(struct asd_sas_phy *sas_phy,
enum phy_func func,
void *funcdata)
{
...
wq->event = CONTROL_PHY;
wq->data = func;
...
INIT_WORK(&wq->work_struct, hisi_sas_wq_process);
queue_work(hisi_hba->wq, &wq->work_struct);
}
void hisi_sas_wq_process(struct work_struct *work)
{
struct hisi_sas_wq *wq =
container_of(work, struct hisi_sas_wq, work_struct);
switch (wq->event) {
case CONTROL_PHY:
hisi_sas_control_phy_work(hisi_hba, wq->data, phy_no);
}
static void hisi_sas_control_phy_work(struct hisi_hba *hisi_hba,
int func,
int phy_no)
{
switch (func) {
case PHY_FUNC_HARD_RESET:
hard_phy_reset_v1_hw(hisi_hba, phy_no)
> Sorry for being unclear, I implied getting rid of them, by having a
> work queue per phy. You can create a structure for each phy like
>
> struct hisi_sas_phy {
> struct hisi_sas *dev; /* pointer to the device */
> unsigned int phy_no;
> struct work_struct phyup_work;
> };
>
> There are probably other things you can put into the same structure.
> When the phy is brought up, you then just start the phyup work for
> that phy, which can retrieve its hisi_sas_phy structure from the
> work_struct pointer, and from there get to the device.
>
> Arnd
>
> .
>
We could create a work_struct for each event, which would be fine.
However we would sometimes still need some way of passing data to the
event, like the phy control example.
next prev parent reply other threads:[~2015-10-19 14:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1444663237-238302-1-git-send-email-john.garry@huawei.com>
[not found] ` <1444663237-238302-6-git-send-email-john.garry@huawei.com>
2015-10-12 15:15 ` [PATCH 05/25] scsi: hisi_sas: allocate memories and create pools Arnd Bergmann
2015-10-13 9:42 ` zhangfei
[not found] ` <1444663237-238302-5-git-send-email-john.garry@huawei.com>
2015-10-12 15:21 ` [PATCH 04/25] scsi: hisi_sas: add scsi host registration Arnd Bergmann
2015-10-13 9:16 ` John Garry
2015-10-13 12:18 ` Arnd Bergmann
[not found] ` <1444663237-238302-8-git-send-email-john.garry@huawei.com>
2015-10-12 15:21 ` [PATCH 07/25] scsi: hisi_sas: add ioremap for device HW Arnd Bergmann
2015-10-13 9:47 ` zhangfei
2015-10-13 12:20 ` Arnd Bergmann
2015-10-13 15:09 ` zhangfei
[not found] ` <1444663237-238302-13-git-send-email-john.garry@huawei.com>
2015-10-12 18:46 ` [PATCH 12/25] scsi: hisi_sas: add v1 HW initialisation code Arnd Bergmann
2015-10-13 12:44 ` John Garry
2015-10-13 12:47 ` Arnd Bergmann
[not found] ` <1444663237-238302-14-git-send-email-john.garry@huawei.com>
2015-10-16 12:55 ` [PATCH 13/25] scsi: hisi_sas: add path from phyup irq to SAS framework Arnd Bergmann
2015-10-16 13:29 ` John Garry
2015-10-16 13:36 ` Arnd Bergmann
2015-10-19 14:11 ` John Garry
2015-10-19 14:26 ` Arnd Bergmann
2015-10-19 14:55 ` John Garry [this message]
2015-10-20 8:40 ` Arnd Bergmann
2015-10-20 9:09 ` John Garry
2015-10-19 8:47 ` [PATCH 00/25] HiSilicon SAS driver John Garry
2015-10-19 8:55 ` Hannes Reinecke
2015-10-19 10:40 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56250473.9090700@huawei.com \
--to=john.garry@huawei.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=hare@suse.de \
--cc=john.garry2@mail.dcu.ie \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=xuwei5@hisilicon.com \
--cc=zhangfei.gao@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).