> Hey Daniel, keeping in mind I can't exactly test it, and that I don't know the > ins and outs of CAPI, the code looks nice and it makes sence to me. > Thanks!
> Some very minor points,
>
> Otherwise
>
> Acked-by: Cyril Bur <cyril...@gmail.com>
>
> >
> > +static inline bool cxl_adapter_link_ok(struct cxl *cxl)
> > +{
> > + struct pci_dev *pdev;
> > +
> > + pdev = to_pci_dev(cxl->dev.parent);
> > + return (pdev->error_state == pci_channel_io_normal);
> > +}
> > +
>
> In the process of reviewing these patches I read the style guide in furthur
> detail and (it doesn't 100% commit one way or the other but) it suggests it
> may
> be wise to get GCC choose if it should inline or not, unless you have an
> reason
> (the macro replacment below being a good example)... Just a thought.
>
This sits in a bunch of hot paths and tight loops... and it's a
glorified macro. I will bear this in mind for the future: I hadn't
thought through the tradeoffs.
>
> So a birdy has informed me these are going to become inlines, you can
> therefore disregard those comments. I am much more in favour of inlines!
>
Yep, they're going to become inlines. yay for inlines.
> > + /* We could be asked to terminate when the hw is down. That
>
> ^
> I'm notoriously bad for having a low care threshhold but I do have a high care
> threshhold for consistency. Double space after period? Are you sure?
>
Fixed.
--
Regards,
Daniel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
