On Tue, Aug 25, 2020 at 04:16:15PM +0300, Andy Shevchenko wrote: > On Mon, Aug 24, 2020 at 06:33:17PM +0200, Cezary Rojewski wrote: > > On 2020-08-20 11:00 AM, Andy Shevchenko wrote: ... > > Another question though: PCI_PM_CTRL. In order for me to make use of this, > > "pm_cap" member would have to be declared for my device. As this is no > > struct pci_dev, catpt has currently no separate member for that purpose. I > > don't believe you want me to add that field into struct's declaration. > > Second option is to define constant for pm_cap offset aka 0x80 within > > registers.h and then do the operations as follows: > > catpt_updatel_pci(cdev, CATPT_PM_CAP + PCI_PM_CTRL, ...) > > > However, in such case I won't be able to make use of current version of > > _updatel_pci() as definition of that macro allows me to skip prefix and type > > implicitly - PMCS (the rest is appended automatically). > > Maybe let's leave it within registers.h altogether so I can actually keep > > using said macro? > > Basically what you do with accessing PCI configuration space via these methods > (catpt_update_pci(), etc) is something repetitive / similar to what xHCI DbC > support code does. I recommend to spend some time to look for similarities here > (catpt) and there (PCI core, xHCI DbC, etc) and, if we were lucky, derive > common helpers for traverse the capability list in more generalized way. Throwing the idea loud: perhaps we may have something like regmap-pci.c to access PCI configuration space and make regmap API to take care of which IO accessors (and locking) will be used. -- With Best Regards, Andy Shevchenko
