Linux-ide Archive on
 help / color / Atom feed
From: Jens Axboe <>
To: Vaibhav Gupta <>
Cc: Bjorn Helgaas <>,
	Bjorn Helgaas <>,
	Bjorn Helgaas <>,
	Vaibhav Gupta <>,
	Bartlomiej Zolnierkiewicz <>,,,,
	Shuah Khan <>
Subject: Re: [PATCH v2] ata: use generic power management
Date: Mon, 27 Jul 2020 14:30:03 -0600
Message-ID: <> (raw)
In-Reply-To: <>

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:
>>>>> The patch is compile-tested only.
>>>> Please test and verify actual functionality, if you're serious
>>>> about potentially getting this into the kernel.
>>> Hello Jens,
>>> Sadly I don't have the hardware. This upgrade is part of my Linux
>>> Kernel Mentorship Program project. Like other PCI drivers which I
>>> have updated, I could do compile-testing only. Though this patch
>>> covers 54 drivers but the actual change is done only in
>>> drivers/ata/libata-core. Since rest of the drivers make use of the
>>> same ata_pci_device_suspend/resume(), it was a chain reaction. I
>>> only had to change variable binding in "struct pci_driver" variable
>>> of dependent drivers.
>> That's understandable, but you should find at least some hardware
>> (maybe remotely accessible) to test this on. I'm not going to apply
>> this without some confidence that it actually works, and compile only
>> testing is a far cry from that. Lots of code compiles, but fails
>> miserably at runtime.
>> While it's touching 54 drivers, at least basic coverage of the most
>> popular choices will give everybody some confidence that it works in
>> general.
> 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

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.

Jens Axboe

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 17:39 Vaibhav Gupta
2020-07-27 17:40 ` Vaibhav Gupta
2020-07-27 17:42   ` Jens Axboe
2020-07-27 17:51     ` Vaibhav Gupta
2020-07-27 17:59       ` Jens Axboe
2020-07-27 18:11         ` Vaibhav Gupta
2020-07-27 20:30           ` Jens Axboe [this message]
2020-07-28  5:17             ` Vaibhav Gupta
2020-07-28 15:51               ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ide Archive on

Archives are clonable:
	git clone --mirror linux-ide/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-ide linux-ide/ \
	public-inbox-index linux-ide

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone