Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1351708imm; Wed, 8 Aug 2018 15:37:56 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzIEHdYZVS74lKpd/5oCadIHVFEYphW9M7W2wA8TYCClIEWHgbSHZLdg9nEZ54m51pAsu5j X-Received: by 2002:a62:1f06:: with SMTP id f6-v6mr4902318pff.140.1533767876717; Wed, 08 Aug 2018 15:37:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533767876; cv=none; d=google.com; s=arc-20160816; b=XcunahAfXb6TOQlCx3FAQZO7laesMY3koZsUFtgVezqBNtCXhtSU/kf6vhzeePPuXt 6ZswE4aTJxDF+jg2BfsBE28hC4RO5I+w63HtVTOzZqLJye2c+Pf7Ehq1OOJmPKo+qb0p RaGu1u/g8IAaHQTKhzutIeMxxnvgGzwjfQEwqL9Tdqy0vo/Kwgd0kYeTn2M7DsrOfRh2 AtBqDGdtKGeR85ZOEkzau7yF6Gr59rZBBgWXEBp3xFk8bOns6Ir7j7ZoY8Ju3LGQZsPX DChc32CdS362PHGlA0o5N21y6V9bspJDCD2t7Hm/w4Jiplat5EOmzjFNxGZ52eKVGoCV cF7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=r3HncyiROr5NZxHnHIdgU1pt9+WDVHKcr6D00d4Tr1w=; b=mZIsfBTLnzkram0sVBF2VYyhWLRRwtCGw9EMTZFTCgwpV739zfGNGb99plxWlYQvWz FiKZx5YrvfTf8rXpSQd9VoxyajPskIgiOT/X+j00d/XSir3KeMl3Pe+TKfWWx/23u/Qd EZFI3SZxEltbXsmMTMUro7y0e2UJ/N/C+wEdtEmuJjyS/pbJfgIT8bAFQsHgtmp6JiLk jCG8JO8SqLqyRlESftcjUYus7jgGIcvBtpvKI2FXIJjHTDg8J+X9PXRU+/6iZf+wGEx7 2EWY7X9yNVxgez8liA3j+QmeefFNRHwNCqezLKfUOZlq3M9F35o+eRfkCcIYsRxcQJCJ S+ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=UtE5CDQB; 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=REJECT sp=REJECT dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v19-v6si5633837pgh.36.2018.08.08.15.37.42; Wed, 08 Aug 2018 15:37:56 -0700 (PDT) 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=@chromium.org header.s=google header.b=UtE5CDQB; 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=REJECT sp=REJECT dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731471AbeHIA6F (ORCPT + 99 others); Wed, 8 Aug 2018 20:58:05 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:37542 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730262AbeHIA6E (ORCPT ); Wed, 8 Aug 2018 20:58:04 -0400 Received: by mail-lj1-f195.google.com with SMTP id v9-v6so2972222ljk.4 for ; Wed, 08 Aug 2018 15:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r3HncyiROr5NZxHnHIdgU1pt9+WDVHKcr6D00d4Tr1w=; b=UtE5CDQBTlHBvTX/EHhc7Q4FszoJFLzDuZzGkj/OEgLwhb1P6P/mGr4xEgUuZC9aOo X3GkfRKMkaVVP76Kjisyaz6j9HXYufZYW/EvC7FD2Lw2IpLfIH1NzxrxciHjxViYGr4P wPJO/1ixmPfLKtMlMiw+urvfTGdMn5s0oXgoQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r3HncyiROr5NZxHnHIdgU1pt9+WDVHKcr6D00d4Tr1w=; b=qtHQrdbVDrf0+Qnirg8S1QSgs959MJ3Tj51edHPnAjjozGZlOn3yh7ySzygtW6kVg7 4qOLHUycu2pwCOEGFeqLnHTZ7eVbTTGAmLrZYL5wYHbI3ZHXQlq9OdvfIHM3OEhOFfUt sO2nYFKJXf7OrQ+3pKQAKtukWg0sIuagI0DZ46X1bsNZavsNoKjkQYif0ddXbsrs72yC 6qAhayvSIfB8k04QVFqOET4pmrU+zmzTxB7uRyvnEtV9VqkNbzFxoaAxd4tRe0ql4Eyb +ghiOxdgJhTlm25pHPF+l47h9amkmRVnucpyEDMUGNe5PKCXEOd78khb61SxjbIFIMQg HFxA== X-Gm-Message-State: AOUpUlF707vKIbj4GsAdlX5b9d+lcn0G6b6hgOhZERj1VxivTX/94asG 5Q822LR8DHYEbBMVUFrYkcVGKlsZXls= X-Received: by 2002:a2e:144f:: with SMTP id 15-v6mr3419191lju.122.1533767777578; Wed, 08 Aug 2018 15:36:17 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id w8-v6sm994154lfe.67.2018.08.08.15.36.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Aug 2018 15:36:15 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id b22-v6so2727345lfa.3 for ; Wed, 08 Aug 2018 15:36:15 -0700 (PDT) X-Received: by 2002:a19:10c4:: with SMTP id 65-v6mr3218305lfq.113.1533767775084; Wed, 08 Aug 2018 15:36:15 -0700 (PDT) MIME-Version: 1.0 References: <20180725201452.81235-1-evgreen@chromium.org> In-Reply-To: From: Evan Green Date: Wed, 8 Aug 2018 15:35:38 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] scsi: ufs: Make sysfs attributes writable To: Stanislav.Nijnikov@wdc.com Cc: Vinayak Holikatti , jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, adrian.hunter@intel.com, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, Bart.VanAssche@wdc.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 8, 2018 at 1:47 AM Stanislav Nijnikov wrote: > > Hi Evan, > > > -----Original Message----- > > From: Evan Green > > Sent: Tuesday, August 7, 2018 9:15 PM > > To: Stanislav Nijnikov > > Cc: Vinayak Holikatti ; jejb@linux.vnet.ibm.com; martin.petersen@oracle.com; adrian.hunter@intel.com; > > linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org; Bart Van Assche > > Subject: Re: [PATCH v3] scsi: ufs: Make sysfs attributes writable > > > > Hi Stanislav. Thanks for the review. > > > > On Mon, Aug 6, 2018 at 2:28 AM Stanislav Nijnikov > > wrote: > > > > > > Hi Evan, > > > > > > > -----Original Message----- > > > > From: Evan Green > > > > Sent: Wednesday, July 25, 2018 11:15 PM > > > > To: Vinayak Holikatti ; James E.J. Bottomley ; Martin K. Petersen > > > > ; Stanislav Nijnikov ; Adrian Hunter ; > > linux- > > > > kernel@vger.kernel.org; linux-scsi@vger.kernel.org; Bart Van Assche > > > > Cc: Evan Green > > > > Subject: [PATCH v3] scsi: ufs: Make sysfs attributes writable > > > > > > > > This change makes the UFS controller's sysfs attributes writable, which > > > > will enable users to modify attributes. This can be useful during factory > > > > provisioning for setting up critical attributes like the reference clock > > > > frequency. > > > > > > > > Signed-off-by: Evan Green > > > > --- > > > > Configfs was determined to be the preferred mechanism for writing the > > > > config descriptor, but attributes also need to be written during setup, > > > > and are already present in sysfs. Making these attributes writable is > > > > also helpful for debugging and experimentation. > > > > > > > > Changes since v2: > > > > - Removed the configuration descriptor changes from the series, > > > > since configfs was the preferred way to write to that, leaving only > > > > this change. > > > > > > > > Changes since v1: > > > > - Reworked the interface to show each unit of the config > > > > descriptor as a separate directory, rather than the previous method I > > > > had of a file for selecting the unit, and then a common set of files > > > > that interacted with whichever unit was selected. I did some kobject > > > > magic to accomplish this. I noticed from Greg KH's reply to Sayali's > > > > patches [1] that configfs might be the preferred method. Let me know > > > > if I should abandon this series in favor of Sayali's, with the > > > > possible exception of "Make sysfs attributes writable". > > > > - Squashed documentation changes into their respective code > > > > changes. > > > > - I decided to keep the config descriptor attributes as their > > > > own files, rather than hiding writes behind device descriptor and unit > > > > descriptor, as I think that's more future proof and true to the UFS spec. > > > > > > > > [1] https://lkml.org/lkml/2018/6/8/210 > > > > > > > > Documentation/ABI/testing/sysfs-driver-ufs | 17 +-------- > > > > drivers/scsi/ufs/ufs-sysfs.c | 58 ++++++++++++++++++++---------- > > > > 2 files changed, 40 insertions(+), 35 deletions(-) > > > > > > ... > > > > diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c > > > > index 8d9332bb7d0c..5e286b9d1aea 100644 > > > > --- a/drivers/scsi/ufs/ufs-sysfs.c > > > > +++ b/drivers/scsi/ufs/ufs-sysfs.c > > > > @@ -655,7 +655,7 @@ static const struct attribute_group ufs_sysfs_flags_group = { > > > > .attrs = ufs_sysfs_device_flags, > > > > }; > > > > > > > > -#define UFS_ATTRIBUTE(_name, _uname) \ > > > > +#define UFS_ATTRIBUTE_SHOW(_name, _uname) \ > > > > static ssize_t _name##_show(struct device *dev, \ > > > > struct device_attribute *attr, char *buf) \ > > > > { \ > > > > @@ -665,25 +665,45 @@ static ssize_t _name##_show(struct device *dev, \ > > > > QUERY_ATTR_IDN##_uname, 0, 0, &value)) \ > > > > return -EINVAL; \ > > > > return sprintf(buf, "0x%08X\n", value); \ > > > > -} \ > > > > -static DEVICE_ATTR_RO(_name) > > > > +} > > > > > > > > -UFS_ATTRIBUTE(boot_lun_enabled, _BOOT_LU_EN); > > > > -UFS_ATTRIBUTE(current_power_mode, _POWER_MODE); > > > > -UFS_ATTRIBUTE(active_icc_level, _ACTIVE_ICC_LVL); > > > > -UFS_ATTRIBUTE(ooo_data_enabled, _OOO_DATA_EN); > > > > -UFS_ATTRIBUTE(bkops_status, _BKOPS_STATUS); > > > > -UFS_ATTRIBUTE(purge_status, _PURGE_STATUS); > > > > -UFS_ATTRIBUTE(max_data_in_size, _MAX_DATA_IN); > > > > -UFS_ATTRIBUTE(max_data_out_size, _MAX_DATA_OUT); > > > > -UFS_ATTRIBUTE(reference_clock_frequency, _REF_CLK_FREQ); > > > > -UFS_ATTRIBUTE(configuration_descriptor_lock, _CONF_DESC_LOCK); > > > > -UFS_ATTRIBUTE(max_number_of_rtt, _MAX_NUM_OF_RTT); > > > > -UFS_ATTRIBUTE(exception_event_control, _EE_CONTROL); > > > > -UFS_ATTRIBUTE(exception_event_status, _EE_STATUS); > > > > -UFS_ATTRIBUTE(ffu_status, _FFU_STATUS); > > > > -UFS_ATTRIBUTE(psa_state, _PSA_STATE); > > > > -UFS_ATTRIBUTE(psa_data_size, _PSA_DATA_SIZE); > > > > +#define UFS_ATTRIBUTE_RO(_name, _uname) \ > > > > +UFS_ATTRIBUTE_SHOW(_name, _uname) \ > > > > +DEVICE_ATTR_RO(_name) > > > It should be static here. > > > > Will fix. > > > > > > > > > + > > > > +#define UFS_ATTRIBUTE_RW(_name, _uname) \ > > > > +UFS_ATTRIBUTE_SHOW(_name, _uname) \ > > > > +static ssize_t _name##_store(struct device *dev, \ > > > > + struct device_attribute *attr, const char *buf, \ > > > > + size_t count) \ > > > > +{ \ > > > > + struct ufs_hba *hba = dev_get_drvdata(dev); \ > > > > + u32 value; \ > > > > + if (kstrtou32(buf, 0, &value)) \ > > > > + return -EINVAL; \ > > > > + if (ufshcd_query_attr(hba, UPIU_QUERY_OPCODE_WRITE_ATTR, \ > > > > + QUERY_ATTR_IDN##_uname, 0, 0, &value)) \ > > > > + return -EINVAL; \ > > > > + return count; \ > > > > +} \ > > > > +static DEVICE_ATTR_RW(_name) > > > > + > > > > +UFS_ATTRIBUTE_RW(boot_lun_enabled, _BOOT_LU_EN); > > > > +UFS_ATTRIBUTE_RO(current_power_mode, _POWER_MODE); > > > > +UFS_ATTRIBUTE_RW(active_icc_level, _ACTIVE_ICC_LVL); > > > > +UFS_ATTRIBUTE_RW(ooo_data_enabled, _OOO_DATA_EN); > > > I would prefer to leave "write once" attributes as read-only. > > > > Oh, but I want those write once attributes, I plan to use them during > > provisioning. Are you worried about accidental writes? My mind jumps > > to some sort of unlock mechanism where you write a magic string into > > an additional sysfs file to unlock the write-once attributes. But the > > last time I proposed a sysfs file that affected the behavior of other > > sysfs files, I got the proverbial raspberry. Any thoughts? > > > Well, I suppose users with root permissions should know what they are > doing. At least, add a special comment for these in the ABI file, not > everyone has access to the UFS spec. Will do. Spin coming up. -Evan