| Message ID | 575554CC02000078000F1E3F@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 06/06/2016 04:47 AM, Jan Beulich wrote: > It's identical to bar_init() now. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > I'm sorry for this 3/2 - I only now noticed that this additional > simplification is now possible. I wonder whether we should also move content of read_dev_bar() into bar_init(). Especially given that it's not really reading a BAR but rather initializing the stashed value. -boris
>>> On 06.06.16 at 15:09, <boris.ostrovsky@oracle.com> wrote: > On 06/06/2016 04:47 AM, Jan Beulich wrote: >> It's identical to bar_init() now. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> I'm sorry for this 3/2 - I only now noticed that this additional >> simplification is now possible. > > I wonder whether we should also move content of read_dev_bar() into > bar_init(). Especially given that it's not really reading a BAR but > rather initializing the stashed value. I had considered that too, but then thought the splitting out of that logic could as well stay. If we were to do that, I'd in fact prefer merging patches 2 and 3 (plus this additional adjustment). Jan
On 06/06/2016 09:54 AM, Jan Beulich wrote: >>>> On 06.06.16 at 15:09, <boris.ostrovsky@oracle.com> wrote: >> On 06/06/2016 04:47 AM, Jan Beulich wrote: >>> It's identical to bar_init() now. >>> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>> --- >>> I'm sorry for this 3/2 - I only now noticed that this additional >>> simplification is now possible. >> I wonder whether we should also move content of read_dev_bar() into >> bar_init(). Especially given that it's not really reading a BAR but >> rather initializing the stashed value. > I had considered that too, but then thought the splitting out of > that logic could as well stay. If we were to do that, I'd in fact > prefer merging patches 2 and 3 (plus this additional adjustment). If you could do that it would be great. (Again, mostly because I think the name is misleading and renaming it to something like dev_bar_init() would also not be good since we already have bar_init()). Thanks. -boris
--- 4.7-rc2-xen-pciback-BAR.orig/drivers/xen/xen-pciback/conf_space_header.c +++ 4.7-rc2-xen-pciback-BAR/drivers/xen/xen-pciback/conf_space_header.c @@ -250,18 +250,6 @@ static void *bar_init(struct pci_dev *de return bar; } -static void *rom_init(struct pci_dev *dev, int offset) -{ - struct pci_bar_info *bar = kzalloc(sizeof(*bar), GFP_KERNEL); - - if (!bar) - return ERR_PTR(-ENOMEM); - - read_dev_bar(dev, bar, offset); - - return bar; -} - static void bar_reset(struct pci_dev *dev, int offset, void *data) { struct pci_bar_info *bar = data; @@ -380,7 +368,7 @@ static const struct config_field header_ { \ .offset = reg_offset, \ .size = 4, \ - .init = rom_init, \ + .init = bar_init, \ .reset = bar_reset, \ .release = bar_release, \ .u.dw.read = bar_read, \
It's identical to bar_init() now. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- I'm sorry for this 3/2 - I only now noticed that this additional simplification is now possible. --- drivers/xen/xen-pciback/conf_space_header.c | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-)