linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


  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).