Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp421551ybl; Wed, 11 Dec 2019 21:41:16 -0800 (PST) X-Google-Smtp-Source: APXvYqxUfPQmQwSOmWmr7+3d482eWur+umaIAOI5vfW/MpDgdK24ud13NtqFv6nG24+wRbgdQyod X-Received: by 2002:a9d:6e89:: with SMTP id a9mr5863146otr.38.1576129276856; Wed, 11 Dec 2019 21:41:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576129276; cv=none; d=google.com; s=arc-20160816; b=RdlJhsAXHOn0v6/e1xjHBQ6/SfaATNGpgaJzdWuOJjIsb3MizwpghK961+77j5F4vD 159g1LjcuYFxhBzKOo3ZcaHIR9zU0W4IKc+egRjkJhRw3MFSl12KAVBQ9+iryMvbb5Q1 gTFK9YLPJBXg4seV30QQqvg9ZojbKVwkIA80SmUCuRVO7TGWjv1WQe09sZ8IPa2rYNLi s4cCIohL0soKz91VhQjDnY3EMMhYcZr+HLGgDbzdZJwU9DC3IJ5qPn5sfZCRqtS7HHNf XGvvlRpNDd3Z7I+ZysvHCSjojtuShsXbcSCQcqCwYyMc6dYwwZ70191CsehipIbQGpR7 9Ogw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=3gRPp7QTPo2KX2Jgdg4xkb4upfF2WCRyDYht55ZZcFM=; b=lg0kVXHngP8xwC0fUv2tsuz1pwZY3KgdUCCmaYRSuUw6sJ6zmoXYH7K9mNrfWsFCAm uSvaZZt+OdYmv0WtlVLf+EV+V8/IZDwCJPTqBuq5hSg+ccfHcVYalkmgF2/zNy84OufR QBHuTOHugVwGgInfNAqZmOHlAGsT0oJ2viETZRe6KMxNSilZqVFL56toqm+jG5BG14GO KenHwxYjL8FIrt3K0XHR+OSvo3fOIsMMTVgDsa6e9Tc78354aRrGD4ViPsyokCPqQbmW UlEjg2FD983E1V3NaLNsEENS0k6Ad2qjz2DVLgSpt1dq5SzW+rgDWa3Uch3U9lR7MNwt LFdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=lYYutyf1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i206si2491302oif.173.2019.12.11.21.41.03; Wed, 11 Dec 2019 21:41:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=lYYutyf1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726840AbfLLFk2 (ORCPT + 99 others); Thu, 12 Dec 2019 00:40:28 -0500 Received: from fllv0015.ext.ti.com ([198.47.19.141]:49040 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725980AbfLLFk2 (ORCPT ); Thu, 12 Dec 2019 00:40:28 -0500 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id xBC5drRP090357; Wed, 11 Dec 2019 23:39:53 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1576129193; bh=3gRPp7QTPo2KX2Jgdg4xkb4upfF2WCRyDYht55ZZcFM=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=lYYutyf1HVfDfxyI4MVbUzwAuUZY9hiOJE882HhTHOThvNUGFXoM/OGlzAYAm/YIe YIO8xKjBNcuehcvWXhYSvYOEwEj//W6PeTNBADSGvTb7SRC6bjBOxC6do1iX2syYLC myAJCGpOmbdmzw+E7fmLe72kUv1z+9GMMTP5f/JM= Received: from DFLE100.ent.ti.com (dfle100.ent.ti.com [10.64.6.21]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id xBC5drQ8079608 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Dec 2019 23:39:53 -0600 Received: from DFLE104.ent.ti.com (10.64.6.25) by DFLE100.ent.ti.com (10.64.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Wed, 11 Dec 2019 23:39:53 -0600 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3 via Frontend Transport; Wed, 11 Dec 2019 23:39:53 -0600 Received: from [172.24.145.136] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id xBC5dkSB093209; Wed, 11 Dec 2019 23:39:47 -0600 Subject: Re: [PATCH v2 2/3] scsi: ufs: Modulize ufs-bsg To: Can Guo , , , , , , , CC: Alim Akhtar , Avri Altman , Pedro Sousa , "James E.J. Bottomley" , "Martin K. Petersen" , Evan Green , Kishon Vijay Abraham I , Stephen Boyd , Stanley Chu , Bean Huo , Bart Van Assche , Venkat Gopalakrishnan , Tomas Winkler , Bjorn Andersson , Arnd Bergmann , open list References: <1576054123-16417-1-git-send-email-cang@codeaurora.org> <0101016ef425ed74-071c2ec2-5aeb-44fa-8889-d9ec60192d44-000000@us-west-2.amazonses.com> From: Vignesh Raghavendra Message-ID: Date: Thu, 12 Dec 2019 11:10:15 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <0101016ef425ed74-071c2ec2-5aeb-44fa-8889-d9ec60192d44-000000@us-west-2.amazonses.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 11/12/19 2:19 pm, Can Guo wrote: > In order to improve the flexibility of ufs-bsg, modulizing it is a good > choice. This change introduces tristate to ufs-bsg to allow users compile > it as an external module. > > Signed-off-by: Can Guo > --- [...] > -int ufs_bsg_probe(struct ufs_hba *hba) > +static int ufs_bsg_probe(struct ufs_hba *hba) > { > - struct device *bsg_dev = &hba->bsg_dev; > + struct device *bsg_dev; > struct Scsi_Host *shost = hba->host; > struct device *parent = &shost->shost_gendev; > struct request_queue *q; > int ret; > > + bsg_dev = kzalloc(sizeof(*bsg_dev), GFP_KERNEL); > + if (!bsg_dev) > + return -ENOMEM; > + > + hba->bsg_dev = bsg_dev; > device_initialize(bsg_dev); > > bsg_dev->parent = get_device(parent); > @@ -217,6 +225,41 @@ int ufs_bsg_probe(struct ufs_hba *hba) > > out: > dev_err(bsg_dev, "fail to initialize a bsg dev %d\n", shost->host_no); > + hba->bsg_dev = NULL; Don't we need to free the associated memory before assigning to NULL? Alternatively can allocation be made with devm_ APIs instead? > put_device(bsg_dev); > return ret; > } > + > +static int __init ufs_bsg_init(void) > +{ > + struct list_head *hba_list = NULL; > + struct ufs_hba *hba; > + int ret = 0; > + > + ufshcd_get_hba_list_lock(&hba_list); > + list_for_each_entry(hba, hba_list, list) { > + ret = ufs_bsg_probe(hba); > + if (ret) > + break; > + } So IIUC, if ufs_bsg_probe() fails for one of the hba instances in the list, then we fail to create bsg device for all remaining instances that follow, which seems too harsh. Regards Vignesh