lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 May 2020 18:46:13 -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 02/13] scsi: ufshpb: Init part I - Read HPB config

On 2020-05-15 03:30, Avri Altman wrote:
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 426073a..bffe699 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -50,6 +50,7 @@
>  #include "ufs_bsg.h"
>  #include <asm/unaligned.h>
>  #include <linux/blkdev.h>
> +#include "ufshpb.h"
>  
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/ufs.h>
> @@ -7341,6 +7342,9 @@ static int ufshcd_add_lus(struct ufs_hba *hba)
>  		hba->clk_scaling.is_allowed = true;
>  	}
>  
> +	if (ufshcd_is_hpb_supported(hba))
> +		ufshpb_probe(hba);
> +
>  	ufs_bsg_probe(hba);
>  	scsi_scan_host(hba->host);
>  	pm_runtime_put_sync(hba->dev);

This looks weird to me because of the following reasons:
- If there are direct calls from the ufshcd module into the ufshpb
  module and if there are direct calls from the ufshpb module into the
  ufshcd module, why has ufshpb been implemented as a kernel module? Or
  in other words, will it ever be possible to load the ufshcd module
  without loading the ufshpb module?
- Patch 3/13 makes ufshpb a device handler. There are no direct calls
  from any upstream SCSI LLD to any upstream device handler. However,
  this patch adds a direct call from the ufshcd module to the ufshpb
  module which is a device handler.

Bart.

Powered by blists - more mailing lists