On Mon, Jul 27, 2020 at 02:30:03PM -0600, Jens Axboe wrote: > On 7/27/20 12:11 PM, Vaibhav Gupta wrote: > > On Mon, Jul 27, 2020 at 11:59:05AM -0600, Jens Axboe wrote: > >> On 7/27/20 11:51 AM, Vaibhav Gupta wrote: > >>> On Mon, Jul 27, 2020 at 11:42:51AM -0600, Jens Axboe wrote: > >>>> On 7/27/20 11:40 AM, Vaibhav Gupta wrote: > > Yes, I agree. Actually with previous drivers, I was able to get help > > from maintainers and/or supporters for the hardware testing. Is that > > possible for this patch? > > It might be, you'll have to ask people to help you, very rarely do people > just test patches unsolicited unless they have some sort of interest in the > feature. > > This is all part of what it takes to get code upstream. Writing the code > is just a small part of it, the bigger part is usually getting it tested > and providing some assurance that you are willing to fix issues when/if > they come up. > > You might want to consider splitting up the patchset a bit - you could > have one patch for the generic bits, then one for each chipset. That > would allow you to at least get some of the work upstream, once tested. > I think I can break this patch into one commit per driver. The reason that all updates got into one single patch is that I made ata_pci_device_suspend/resume() static and exported just the ata_pci_device_pm_ops variable. Thus, all the driver using .suspend/.resume() had to be updated in a single patch. First I will make changes in drivers/ata/libata-core.c, but won't make any function static. Thus, each driver can be updated in independent commits without breaking anything. And then in the last commit, I can hide the unnecessary .suspend()/.resume() callbacks. This will create patch-series of 55 or 56 patches. Will this approach work? Thanks Vaibhav Gupta > -- > Jens Axboe >
