* [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface
@ 2017-02-17 21:41 Eddie James
2017-02-20 5:42 ` Joel Stanley
2017-02-20 6:54 ` Jeremy Kerr
0 siblings, 2 replies; 7+ messages in thread
From: Eddie James @ 2017-02-17 21:41 UTC (permalink / raw)
To: openbmc; +Cc: joel, cbostic, Edward A. 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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface
2017-02-17 21:41 [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface Eddie James
@ 2017-02-20 5:42 ` Joel Stanley
2017-02-20 15:08 ` Eddie James
2017-02-20 6:54 ` Jeremy Kerr
1 sibling, 1 reply; 7+ messages in thread
From: Joel Stanley @ 2017-02-20 5:42 UTC (permalink / raw)
To: Eddie James; +Cc: OpenBMC Maillist, Christopher Bostic, Edward A. James
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface
2017-02-17 21:41 [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface Eddie James
2017-02-20 5:42 ` Joel Stanley
@ 2017-02-20 6:54 ` Jeremy Kerr
2017-02-20 14:59 ` Eddie James
1 sibling, 1 reply; 7+ messages in thread
From: Jeremy Kerr @ 2017-02-20 6:54 UTC (permalink / raw)
To: Eddie James, openbmc; +Cc: Edward A. James, cbostic
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface
2017-02-20 6:54 ` Jeremy Kerr
@ 2017-02-20 14:59 ` Eddie James
2017-02-21 3:40 ` Jeremy Kerr
0 siblings, 1 reply; 7+ messages in thread
From: Eddie James @ 2017-02-20 14:59 UTC (permalink / raw)
To: Jeremy Kerr, openbmc; +Cc: Edward A. James, cbostic
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface
2017-02-20 5:42 ` Joel Stanley
@ 2017-02-20 15:08 ` Eddie James
2017-02-20 22:25 ` Eddie James
0 siblings, 1 reply; 7+ messages in thread
From: Eddie James @ 2017-02-20 15:08 UTC (permalink / raw)
To: Joel Stanley; +Cc: OpenBMC Maillist, Christopher Bostic, Edward A. 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
>>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface
2017-02-20 15:08 ` Eddie James
@ 2017-02-20 22:25 ` Eddie James
0 siblings, 0 replies; 7+ messages in thread
From: Eddie James @ 2017-02-20 22:25 UTC (permalink / raw)
To: Joel Stanley; +Cc: Edward A. James, OpenBMC Maillist, Christopher Bostic
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
>>>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface
2017-02-20 14:59 ` Eddie James
@ 2017-02-21 3:40 ` Jeremy Kerr
0 siblings, 0 replies; 7+ messages in thread
From: Jeremy Kerr @ 2017-02-21 3:40 UTC (permalink / raw)
To: Eddie James, openbmc; +Cc: Edward A. James, cbostic
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-21 3:40 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-17 21:41 [PATCH linux dev-4.7] drivers: fsi: scom: Add reset functionality and sysfs interface Eddie James
2017-02-20 5:42 ` Joel Stanley
2017-02-20 15:08 ` Eddie James
2017-02-20 22:25 ` Eddie James
2017-02-20 6:54 ` Jeremy Kerr
2017-02-20 14:59 ` Eddie James
2017-02-21 3:40 ` Jeremy Kerr
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.