[PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface

[PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface

[Eddie James]

From: "Edward A. James" <eajames@us.ibm.com>

full reset only

Signed-off-by: Edward A. James <eajames@us.ibm.com>
---
 drivers/fsi/fsi-scom.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index ff8267b..c73bd91 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -32,7 +32,10 @@
 #define SCOM_DATA0_REG		0x00
 #define SCOM_DATA1_REG		0x04
 #define SCOM_CMD_REG		0x08
+#define SCOM_FSI2PIB_RESET_REG	0x18
 #define SCOM_RESET_REG		0x1C
+#define SCOM_COMP_MASK_REG	0x30
+#define SCOM_TRUE_MASK_REG	0x34
 
 #define SCOM_RESET_CMD		0x80000000
 #define SCOM_WRITE_CMD		0x80000000
@@ -156,7 +159,7 @@ static ssize_t scom_write(struct file *filep, const char __user *buf,
 	if (rc)
 		dev_dbg(dev, "put_scom failed with:%d\n", rc);
 
-	return rc;
+	return rc ? rc : len;
 }
 
 static loff_t scom_llseek(struct file *file, loff_t offset, int whence)
@@ -181,6 +184,48 @@ static const struct file_operations scom_fops = {
 	.write	= scom_write,
 };
 
+static int scom_reset_fsi2pib(struct fsi_device *fsi_dev)
+{
+	int rc;
+	u32 dummy = 0xFFFFFFFF;
+
+	rc = fsi_device_write(fsi_dev, SCOM_FSI2PIB_RESET_REG, &dummy,
+			      sizeof(u32));
+	if (rc)
+		dev_dbg(&fsi_dev->dev,
+			"failed to write fsi2pib reset register rc:%d\n", rc);
+
+	return rc;
+}
+
+static int scom_full_reset(struct fsi_device *fsi_dev)
+{
+	int rc = 0;
+	u32 dummy = 0xFFFFFFFF;
+
+	rc = fsi_device_write(fsi_dev, SCOM_RESET_REG, &dummy, sizeof(u32));
+	if (rc) {
+		dev_dbg(&fsi_dev->dev,
+			"failed to write scom reset register rc:%d\n", rc);
+		return rc;
+	}
+
+	return scom_reset_fsi2pib(fsi_dev);
+}
+
+static ssize_t store_reset_register(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t count)
+{
+	int rc;
+	struct fsi_device *fsi_dev = to_fsi_dev(dev);
+
+	rc = scom_full_reset(fsi_dev);
+
+	return rc ? rc : count;
+}
+DEVICE_ATTR(reset, 0200, NULL, store_reset_register);
+
 static int scom_probe(struct device *dev)
 {
 	struct fsi_device *fsi_dev = to_fsi_dev(dev);
@@ -200,6 +245,8 @@ static int scom_probe(struct device *dev)
 	scom->mdev.parent = dev;
 	list_add(&scom->link, &scom_devices);
 
+	device_create_file(dev, &dev_attr_reset);
+
 	return misc_register(&scom->mdev);
 }
 
@@ -207,6 +254,8 @@ static int scom_remove(struct device *dev)
 {
 	struct scom_device *scom, *scom_tmp;
 	struct fsi_device *fsi_dev = to_fsi_dev(dev);
+
+	device_remove_file(dev, &dev_attr_reset);
 	
 	list_for_each_entry_safe(scom, scom_tmp, &scom_devices, link) {
 		if (scom->fsi_dev == fsi_dev) {
-- 
1.8.3.1

Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface

[Joel Stanley]

On Sat, Feb 18, 2017 at 8:11 AM, Eddie James <eajames@linux.vnet.ibm.com> wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
>
> full reset only

The commit message needs some work. Use full sentences, explain why
the patch is required.

>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> ---
>  drivers/fsi/fsi-scom.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
> index ff8267b..c73bd91 100644
> --- a/drivers/fsi/fsi-scom.c
> +++ b/drivers/fsi/fsi-scom.c
> @@ -32,7 +32,10 @@
>  #define SCOM_DATA0_REG         0x00
>  #define SCOM_DATA1_REG         0x04
>  #define SCOM_CMD_REG           0x08
> +#define SCOM_FSI2PIB_RESET_REG 0x18
>  #define SCOM_RESET_REG         0x1C
> +#define SCOM_COMP_MASK_REG     0x30
> +#define SCOM_TRUE_MASK_REG     0x34
>
>  #define SCOM_RESET_CMD         0x80000000
>  #define SCOM_WRITE_CMD         0x80000000
> @@ -156,7 +159,7 @@ static ssize_t scom_write(struct file *filep, const char __user *buf,
>         if (rc)
>                 dev_dbg(dev, "put_scom failed with:%d\n", rc);
>
> -       return rc;
> +       return rc ? rc : len;

This looks like an unrelated fix.

>  }
>
>  static loff_t scom_llseek(struct file *file, loff_t offset, int whence)
> @@ -181,6 +184,48 @@ static const struct file_operations scom_fops = {
>         .write  = scom_write,
>  };
>
> +static int scom_reset_fsi2pib(struct fsi_device *fsi_dev)
> +{
> +       int rc;
> +       u32 dummy = 0xFFFFFFFF;
> +
> +       rc = fsi_device_write(fsi_dev, SCOM_FSI2PIB_RESET_REG, &dummy,
> +                             sizeof(u32));
> +       if (rc)
> +               dev_dbg(&fsi_dev->dev,
> +                       "failed to write fsi2pib reset register rc:%d\n", rc);

Is this expected behaviour? If not, use dev_err.

> +
> +       return rc;
> +}
> +
> +static int scom_full_reset(struct fsi_device *fsi_dev)
> +{
> +       int rc = 0;
> +       u32 dummy = 0xFFFFFFFF;
> +
> +       rc = fsi_device_write(fsi_dev, SCOM_RESET_REG, &dummy, sizeof(u32));

sizeof(dummy)

> +       if (rc) {
> +               dev_dbg(&fsi_dev->dev,
> +                       "failed to write scom reset register rc:%d\n", rc);
> +               return rc;
> +       }
> +
> +       return scom_reset_fsi2pib(fsi_dev);
> +}
> +
> +static ssize_t store_reset_register(struct device *dev,
> +                                   struct device_attribute *attr,
> +                                   const char *buf, size_t count)
> +{
> +       int rc;
> +       struct fsi_device *fsi_dev = to_fsi_dev(dev);
> +
> +       rc = scom_full_reset(fsi_dev);
> +
> +       return rc ? rc : count;
> +}
> +DEVICE_ATTR(reset, 0200, NULL, store_reset_register);
> +
>  static int scom_probe(struct device *dev)
>  {
>         struct fsi_device *fsi_dev = to_fsi_dev(dev);
> @@ -200,6 +245,8 @@ static int scom_probe(struct device *dev)
>         scom->mdev.parent = dev;
>         list_add(&scom->link, &scom_devices);
>
> +       device_create_file(dev, &dev_attr_reset);
> +

What is the expected behaviour if two different userspace programs
have the reset and chardev open?

>         return misc_register(&scom->mdev);
>  }
>
> @@ -207,6 +254,8 @@ static int scom_remove(struct device *dev)
>  {
>         struct scom_device *scom, *scom_tmp;
>         struct fsi_device *fsi_dev = to_fsi_dev(dev);
> +
> +       device_remove_file(dev, &dev_attr_reset);
>
>         list_for_each_entry_safe(scom, scom_tmp, &scom_devices, link) {
>                 if (scom->fsi_dev == fsi_dev) {
> --
> 1.8.3.1
>

Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface

[Jeremy Kerr]

Hi Eddie,

The changelog doesn't have much context, so a bit of a question:

> +static ssize_t store_reset_register(struct device *dev,
> +				    struct device_attribute *attr,
> +				    const char *buf, size_t count)
> +{
> +	int rc;
> +	struct fsi_device *fsi_dev = to_fsi_dev(dev);
> +
> +	rc = scom_full_reset(fsi_dev);
> +
> +	return rc ? rc : count;
> +}
> +DEVICE_ATTR(reset, 0200, NULL, store_reset_register);
> +

How does this interact with the scom read/write operations? Having
different interfaces access methods (file for one, sysfs interface for
another)for both seems like an invitation for trouble - would this make
more sense as an ioctl on the existing fd?

Cheers,


Jeremy

Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface

[Eddie James]

On 02/20/2017 12:54 AM, Jeremy Kerr wrote:
> Hi Eddie,
>
> The changelog doesn't have much context, so a bit of a question:
>
>> +static ssize_t store_reset_register(struct device *dev,
>> +				    struct device_attribute *attr,
>> +				    const char *buf, size_t count)
>> +{
>> +	int rc;
>> +	struct fsi_device *fsi_dev = to_fsi_dev(dev);
>> +
>> +	rc = scom_full_reset(fsi_dev);
>> +
>> +	return rc ? rc : count;
>> +}
>> +DEVICE_ATTR(reset, 0200, NULL, store_reset_register);
>> +
> How does this interact with the scom read/write operations? Having
> different interfaces access methods (file for one, sysfs interface for
> another)for both seems like an invitation for trouble - would this make
> more sense as an ioctl on the existing fd?

It would, but I was under the impression ioctls were frowned upon for 
some reason? Since we only have one option (reset), I felt a sysfs entry 
made more sense for now? It doesn't interact at all with the read/write 
operations, though I suppose if you wrote reset while in the middle of a 
getscom/putscom, you'd probably end up with a bus error. I'd classify 
that as user error. We could add some sort of locking.

>
> Cheers,
>
>
> Jeremy
>

Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface

[Eddie James]

On 02/19/2017 11:42 PM, Joel Stanley wrote:
> On Sat, Feb 18, 2017 at 8:11 AM, Eddie James <eajames@linux.vnet.ibm.com> wrote:
>> From: "Edward A. James" <eajames@us.ibm.com>
>>
>> full reset only
> The commit message needs some work. Use full sentences, explain why
> the patch is required.

Ok.

>
>> Signed-off-by: Edward A. James <eajames@us.ibm.com>
>> ---
>>   drivers/fsi/fsi-scom.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
>> index ff8267b..c73bd91 100644
>> --- a/drivers/fsi/fsi-scom.c
>> +++ b/drivers/fsi/fsi-scom.c
>> @@ -32,7 +32,10 @@
>>   #define SCOM_DATA0_REG         0x00
>>   #define SCOM_DATA1_REG         0x04
>>   #define SCOM_CMD_REG           0x08
>> +#define SCOM_FSI2PIB_RESET_REG 0x18
>>   #define SCOM_RESET_REG         0x1C
>> +#define SCOM_COMP_MASK_REG     0x30
>> +#define SCOM_TRUE_MASK_REG     0x34
>>
>>   #define SCOM_RESET_CMD         0x80000000
>>   #define SCOM_WRITE_CMD         0x80000000
>> @@ -156,7 +159,7 @@ static ssize_t scom_write(struct file *filep, const char __user *buf,
>>          if (rc)
>>                  dev_dbg(dev, "put_scom failed with:%d\n", rc);
>>
>> -       return rc;
>> +       return rc ? rc : len;
> This looks like an unrelated fix.

Yes, I guess a separate patch is in order.

>
>>   }
>>
>>   static loff_t scom_llseek(struct file *file, loff_t offset, int whence)
>> @@ -181,6 +184,48 @@ static const struct file_operations scom_fops = {
>>          .write  = scom_write,
>>   };
>>
>> +static int scom_reset_fsi2pib(struct fsi_device *fsi_dev)
>> +{
>> +       int rc;
>> +       u32 dummy = 0xFFFFFFFF;
>> +
>> +       rc = fsi_device_write(fsi_dev, SCOM_FSI2PIB_RESET_REG, &dummy,
>> +                             sizeof(u32));
>> +       if (rc)
>> +               dev_dbg(&fsi_dev->dev,
>> +                       "failed to write fsi2pib reset register rc:%d\n", rc);
> Is this expected behaviour? If not, use dev_err.
The rest of the driver uses dev_dbg even in error situations, so I tried 
to follow suit here.
>
>> +
>> +       return rc;
>> +}
>> +
>> +static int scom_full_reset(struct fsi_device *fsi_dev)
>> +{
>> +       int rc = 0;
>> +       u32 dummy = 0xFFFFFFFF;
>> +
>> +       rc = fsi_device_write(fsi_dev, SCOM_RESET_REG, &dummy, sizeof(u32));
> sizeof(dummy)
>
>> +       if (rc) {
>> +               dev_dbg(&fsi_dev->dev,
>> +                       "failed to write scom reset register rc:%d\n", rc);
>> +               return rc;
>> +       }
>> +
>> +       return scom_reset_fsi2pib(fsi_dev);
>> +}
>> +
>> +static ssize_t store_reset_register(struct device *dev,
>> +                                   struct device_attribute *attr,
>> +                                   const char *buf, size_t count)
>> +{
>> +       int rc;
>> +       struct fsi_device *fsi_dev = to_fsi_dev(dev);
>> +
>> +       rc = scom_full_reset(fsi_dev);
>> +
>> +       return rc ? rc : count;
>> +}
>> +DEVICE_ATTR(reset, 0200, NULL, store_reset_register);
>> +
>>   static int scom_probe(struct device *dev)
>>   {
>>          struct fsi_device *fsi_dev = to_fsi_dev(dev);
>> @@ -200,6 +245,8 @@ static int scom_probe(struct device *dev)
>>          scom->mdev.parent = dev;
>>          list_add(&scom->link, &scom_devices);
>>
>> +       device_create_file(dev, &dev_attr_reset);
>> +
> What is the expected behaviour if two different userspace programs
> have the reset and chardev open?

Probably a bus error or some sort of scom error if you write reset while 
you have a getscom/putscom operation going. Could add some locking?

Thanks,
Eddie

>
>>          return misc_register(&scom->mdev);
>>   }
>>
>> @@ -207,6 +254,8 @@ static int scom_remove(struct device *dev)
>>   {
>>          struct scom_device *scom, *scom_tmp;
>>          struct fsi_device *fsi_dev = to_fsi_dev(dev);
>> +
>> +       device_remove_file(dev, &dev_attr_reset);
>>
>>          list_for_each_entry_safe(scom, scom_tmp, &scom_devices, link) {
>>                  if (scom->fsi_dev == fsi_dev) {
>> --
>> 1.8.3.1
>>

Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface

[Eddie James]

I'm abandoning this. The reset procedure is simple enough to do from the 
cronus ADAL layer. In FSP code it had a bunch of checks for cfam type, 
so I thought it would continue to make sense in the driver. But we don't 
need that here.

Thanks,

Eddie


On 02/20/2017 09:08 AM, Eddie James wrote:
>
>
> On 02/19/2017 11:42 PM, Joel Stanley wrote:
>> On Sat, Feb 18, 2017 at 8:11 AM, Eddie James 
>> <eajames@linux.vnet.ibm.com> wrote:
>>> From: "Edward A. James" <eajames@us.ibm.com>
>>>
>>> full reset only
>> The commit message needs some work. Use full sentences, explain why
>> the patch is required.
>
> Ok.
>
>>
>>> Signed-off-by: Edward A. James <eajames@us.ibm.com>
>>> ---
>>>   drivers/fsi/fsi-scom.c | 51 
>>> +++++++++++++++++++++++++++++++++++++++++++++++++-
>>>   1 file changed, 50 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
>>> index ff8267b..c73bd91 100644
>>> --- a/drivers/fsi/fsi-scom.c
>>> +++ b/drivers/fsi/fsi-scom.c
>>> @@ -32,7 +32,10 @@
>>>   #define SCOM_DATA0_REG         0x00
>>>   #define SCOM_DATA1_REG         0x04
>>>   #define SCOM_CMD_REG           0x08
>>> +#define SCOM_FSI2PIB_RESET_REG 0x18
>>>   #define SCOM_RESET_REG         0x1C
>>> +#define SCOM_COMP_MASK_REG     0x30
>>> +#define SCOM_TRUE_MASK_REG     0x34
>>>
>>>   #define SCOM_RESET_CMD         0x80000000
>>>   #define SCOM_WRITE_CMD         0x80000000
>>> @@ -156,7 +159,7 @@ static ssize_t scom_write(struct file *filep, 
>>> const char __user *buf,
>>>          if (rc)
>>>                  dev_dbg(dev, "put_scom failed with:%d\n", rc);
>>>
>>> -       return rc;
>>> +       return rc ? rc : len;
>> This looks like an unrelated fix.
>
> Yes, I guess a separate patch is in order.
>
>>
>>>   }
>>>
>>>   static loff_t scom_llseek(struct file *file, loff_t offset, int 
>>> whence)
>>> @@ -181,6 +184,48 @@ static const struct file_operations scom_fops = {
>>>          .write  = scom_write,
>>>   };
>>>
>>> +static int scom_reset_fsi2pib(struct fsi_device *fsi_dev)
>>> +{
>>> +       int rc;
>>> +       u32 dummy = 0xFFFFFFFF;
>>> +
>>> +       rc = fsi_device_write(fsi_dev, SCOM_FSI2PIB_RESET_REG, &dummy,
>>> +                             sizeof(u32));
>>> +       if (rc)
>>> +               dev_dbg(&fsi_dev->dev,
>>> +                       "failed to write fsi2pib reset register 
>>> rc:%d\n", rc);
>> Is this expected behaviour? If not, use dev_err.
> The rest of the driver uses dev_dbg even in error situations, so I 
> tried to follow suit here.
>>
>>> +
>>> +       return rc;
>>> +}
>>> +
>>> +static int scom_full_reset(struct fsi_device *fsi_dev)
>>> +{
>>> +       int rc = 0;
>>> +       u32 dummy = 0xFFFFFFFF;
>>> +
>>> +       rc = fsi_device_write(fsi_dev, SCOM_RESET_REG, &dummy, 
>>> sizeof(u32));
>> sizeof(dummy)
>>
>>> +       if (rc) {
>>> +               dev_dbg(&fsi_dev->dev,
>>> +                       "failed to write scom reset register 
>>> rc:%d\n", rc);
>>> +               return rc;
>>> +       }
>>> +
>>> +       return scom_reset_fsi2pib(fsi_dev);
>>> +}
>>> +
>>> +static ssize_t store_reset_register(struct device *dev,
>>> +                                   struct device_attribute *attr,
>>> +                                   const char *buf, size_t count)
>>> +{
>>> +       int rc;
>>> +       struct fsi_device *fsi_dev = to_fsi_dev(dev);
>>> +
>>> +       rc = scom_full_reset(fsi_dev);
>>> +
>>> +       return rc ? rc : count;
>>> +}
>>> +DEVICE_ATTR(reset, 0200, NULL, store_reset_register);
>>> +
>>>   static int scom_probe(struct device *dev)
>>>   {
>>>          struct fsi_device *fsi_dev = to_fsi_dev(dev);
>>> @@ -200,6 +245,8 @@ static int scom_probe(struct device *dev)
>>>          scom->mdev.parent = dev;
>>>          list_add(&scom->link, &scom_devices);
>>>
>>> +       device_create_file(dev, &dev_attr_reset);
>>> +
>> What is the expected behaviour if two different userspace programs
>> have the reset and chardev open?
>
> Probably a bus error or some sort of scom error if you write reset 
> while you have a getscom/putscom operation going. Could add some locking?
>
> Thanks,
> Eddie
>
>>
>>>          return misc_register(&scom->mdev);
>>>   }
>>>
>>> @@ -207,6 +254,8 @@ static int scom_remove(struct device *dev)
>>>   {
>>>          struct scom_device *scom, *scom_tmp;
>>>          struct fsi_device *fsi_dev = to_fsi_dev(dev);
>>> +
>>> +       device_remove_file(dev, &dev_attr_reset);
>>>
>>>          list_for_each_entry_safe(scom, scom_tmp, &scom_devices, 
>>> link) {
>>>                  if (scom->fsi_dev == fsi_dev) {
>>> -- 
>>> 1.8.3.1
>>>
>

Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface

[Jeremy Kerr]

Hi Eddie,

>>> +static ssize_t store_reset_register(struct device *dev,
>>> +                    struct device_attribute *attr,
>>> +                    const char *buf, size_t count)
>>> +{
>>> +    int rc;
>>> +    struct fsi_device *fsi_dev = to_fsi_dev(dev);
>>> +
>>> +    rc = scom_full_reset(fsi_dev);
>>> +
>>> +    return rc ? rc : count;
>>> +}
>>> +DEVICE_ATTR(reset, 0200, NULL, store_reset_register);
>>> +
>> How does this interact with the scom read/write operations? Having
>> different interfaces access methods (file for one, sysfs interface for
>> another)for both seems like an invitation for trouble - would this make
>> more sense as an ioctl on the existing fd?
> 
> It would, but I was under the impression ioctls were frowned upon for
> some reason?

The downside of an ioctl is that it needs a new definition in kernel
headers (ie, the ioctl number and any structures required for
input/output data).

However, I think it's entirely suitable in this case - we have the usual
flow of data (the scoms) over read()/write(), and control operations
(reset) using an ioctl.

However, that assumes that the reset is something that a user may want
to issue in normal operation, rather than a debug or diagnosis event. Is
that the case here?

Cheers,


Jeremy