| Message ID | 20200716090432.13691-1-miaoqinglang@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [-next] rsxx: Convert to DEFINE_SHOW_ATTRIBUTE | expand |
On 7/16/20 3:04 AM, Qinglang Miao wrote: > From: Liu Shixin <liushixin2@huawei.com> > > 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.
在 2020/7/16 23:45, Jens Axboe 写道: > On 7/16/20 3:04 AM, Qinglang Miao wrote: >> From: Liu Shixin <liushixin2@huawei.com> >> >> 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 <liushixin2@huawei.com> >>> >>> 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.
在 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 <liushixin2@huawei.com> >>>> >>>> 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 <liushixin2@huawei.com> >>>> >>>> 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. >
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;