[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52b5a1c6-38fd-7231-f6c9-b560c3ca9372@acm.org>
Date: Fri, 15 May 2020 18:52:00 -0700
From: Bart Van Assche <bvanassche@....org>
To: Avri Altman <avri.altman@....com>,
"James E . J . Bottomley" <jejb@...ux.vnet.ibm.com>,
"Martin K . Petersen" <martin.petersen@...cle.com>,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: alim.akhtar@...sung.com, asutoshd@...eaurora.org,
Zang Leigang <zangleigang@...ilicon.com>,
Avi Shchislowski <avi.shchislowski@....com>,
Bean Huo <beanhuo@...ron.com>, cang@...eaurora.org,
stanley.chu@...iatek.com,
MOHAMMED RAFIQ KAMAL BASHA <md.rafiq@...sung.com>,
Sang-yoon Oh <sangyoon.oh@...sung.com>,
yongmyung lee <ymhungry.lee@...sung.com>,
Jinyoung CHOI <j-young.choi@...sung.com>
Subject: Re: [RFC PATCH 04/13] scsi: ufs: ufshpb: Init part II - Attach scsi
device
On 2020-05-15 03:30, Avri Altman wrote:
> @@ -4628,6 +4628,9 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
>
> ufshcd_get_lu_power_on_wp_status(hba, sdev);
>
> + if (ufshcd_is_hpb_supported(hba))
> + ufshpb_attach_sdev(hba, sdev);
> +
> return 0;
> }
This approach is unusual because:
- Direct calls from the ufshcd module into the ufshpb module make it
impossible to unload the latter kernel module.
- No other SCSI LLD calls directly into a device handler.
Thanks,
Bart.
Powered by blists - more mailing lists