From: Liu Shixin <[email protected]>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Liu Shixin <[email protected]>
---
drivers/block/rsxx/core.c | 31 ++++---------------------------
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index e631749e1..9c35fa35b 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -150,16 +150,6 @@ static int rsxx_attr_stats_show(struct seq_file *m, void *p)
return 0;
}
-static int rsxx_attr_stats_open(struct inode *inode, struct file *file)
-{
- return single_open(file, rsxx_attr_stats_show, inode->i_private);
-}
-
-static int rsxx_attr_pci_regs_open(struct inode *inode, struct file *file)
-{
- return single_open(file, rsxx_attr_pci_regs_show, inode->i_private);
-}
-
static ssize_t rsxx_cram_read(struct file *fp, char __user *ubuf,
size_t cnt, loff_t *ppos)
{
@@ -206,21 +196,8 @@ static const struct file_operations debugfs_cram_fops = {
.write = rsxx_cram_write,
};
-static const struct file_operations debugfs_stats_fops = {
- .owner = THIS_MODULE,
- .open = rsxx_attr_stats_open,
- .read_iter = seq_read_iter,
- .llseek = seq_lseek,
- .release = single_release,
-};
-
-static const struct file_operations debugfs_pci_regs_fops = {
- .owner = THIS_MODULE,
- .open = rsxx_attr_pci_regs_open,
- .read_iter = seq_read_iter,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(rsxx_attr_stats);
+DEFINE_SHOW_ATTRIBUTE(rsxx_attr_pci_regs);
static void rsxx_debugfs_dev_new(struct rsxx_cardinfo *card)
{
@@ -234,13 +211,13 @@ static void rsxx_debugfs_dev_new(struct rsxx_cardinfo *card)
debugfs_stats = debugfs_create_file("stats", 0444,
card->debugfs_dir, card,
- &debugfs_stats_fops);
+ &rsxx_attr_stats_fops);
if (IS_ERR_OR_NULL(debugfs_stats))
goto failed_debugfs_stats;
debugfs_pci_regs = debugfs_create_file("pci_regs", 0444,
card->debugfs_dir, card,
- &debugfs_pci_regs_fops);
+ &rsxx_attr_pci_regs_fops);
if (IS_ERR_OR_NULL(debugfs_pci_regs))
goto failed_debugfs_pci_regs;
--
2.17.1
On 7/16/20 3:04 AM, Qinglang Miao wrote:
> From: Liu Shixin <[email protected]>
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
None of these apply against the 5.9 block tree, looks like some
read -> read_iter conversion has happened in another branch that
I'm not privy to.
--
Jens Axboe
在 2020/7/16 23:45, Jens Axboe 写道:
> On 7/16/20 3:04 AM, Qinglang Miao wrote:
>> From: Liu Shixin <[email protected]>
>>
>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> None of these apply against the 5.9 block tree, looks like some
> read -> read_iter conversion has happened in another branch that
> I'm not privy to.
Hi Jens,
Sorry I didn't mention it in commit log, but this patch is based
on linux-next where commit <4d4901c6d7> has switched over direct
seq_read method calls to seq_read_iter, this is why there's conflict in
your apply.
Do you think I should send a new patch based on 5.8rc?
Thanks.
On 7/16/20 7:37 PM, miaoqinglang wrote:
>
> 在 2020/7/16 23:45, Jens Axboe 写道:
>> On 7/16/20 3:04 AM, Qinglang Miao wrote:
>>> From: Liu Shixin <[email protected]>
>>>
>>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>> None of these apply against the 5.9 block tree, looks like some
>> read -> read_iter conversion has happened in another branch that
>> I'm not privy to.
>
> Hi Jens,
>
> Sorry I didn't mention it in commit log, but this patch is based
> on linux-next where commit <4d4901c6d7> has switched over direct
> seq_read method calls to seq_read_iter, this is why there's conflict in
> your apply.
>
> Do you think I should send a new patch based on 5.8rc?
That'll just create a needless conflict. But I don't even know what tree
is carrying the patch that changes it to use seq_read_iter, so hard to
make other suggestions.
Alternatively, I can hang on to them until the other change hits
mainline, and then queue them up after that.
--
Jens Axboe
在 2020/7/17 10:16, Jens Axboe 写道:
> On 7/16/20 7:37 PM, miaoqinglang wrote:
>>
>> 在 2020/7/16 23:45, Jens Axboe 写道:
>>> On 7/16/20 3:04 AM, Qinglang Miao wrote:
>>>> From: Liu Shixin <[email protected]>
>>>>
>>>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>>> None of these apply against the 5.9 block tree, looks like some
>>> read -> read_iter conversion has happened in another branch that
>>> I'm not privy to.
>>
>> Hi Jens,
>>
>> Sorry I didn't mention it in commit log, but this patch is based
>> on linux-next where commit <4d4901c6d7> has switched over direct
>> seq_read method calls to seq_read_iter, this is why there's conflict in
>> your apply.
>>
>> Do you think I should send a new patch based on 5.8rc?
>
> That'll just create a needless conflict. But I don't even know what tree
> is carrying the patch that changes it to use seq_read_iter, so hard to
> make other suggestions.
This patch is against linux-next, which is ahead of both
linux-block and mainline tree. Here's the interlinkage:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/4d4901c6d748efab8aab6e7d2405dadaed0bea50](javascript:;)
or you can find the commit <4d4901c6d7> which changes seq_read to
seq_read_iter with the -next tag, in fact, it's just a simple script:
sed -i -e 's/\.read\(\s*=\s*\)seq_read/\.read_iter\1seq_read_iter/g'
By the way, there won't be needless confict because seq_read in both
file and macro are switched to seq_read_iter together.
>
> Alternatively, I can hang on to them until the other change hits
> mainline, and then queue them up after that.
>
That looks good to me. Let me know if patch based on 5.8rc is needed.
Thanks.
Qinglang
.
在 2020/7/17 10:16, Jens Axboe 写道:
> On 7/16/20 7:37 PM, miaoqinglang wrote:
>>
>> 在 2020/7/16 23:45, Jens Axboe 写道:
>>> On 7/16/20 3:04 AM, Qinglang Miao wrote:
>>>> From: Liu Shixin <[email protected]>
>>>>
>>>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>>> None of these apply against the 5.9 block tree, looks like some
>>> read -> read_iter conversion has happened in another branch that
>>> I'm not privy to.
>>
>> Hi Jens,
>>
>> Sorry I didn't mention it in commit log, but this patch is based
>> on linux-next where commit <4d4901c6d7> has switched over direct
>> seq_read method calls to seq_read_iter, this is why there's conflict in
>> your apply.
>>
>> Do you think I should send a new patch based on 5.8rc?
>
> That'll just create a needless conflict. But I don't even know what tree
> is carrying the patch that changes it to use seq_read_iter, so hard to
> make other suggestions.
>
Hi Jens,
I resent a new patch against linux-next(20200917), and it can
be applied to mainline cleanly now.
Thanks.
> Alternatively, I can hang on to them until the other change hits
> mainline, and then queue them up after that.
>