Linux ATA/IDE development
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Damien Le Moal <dlemoal@kernel.org>,
	Werner Fischer <devlists@wefi.net>,
	Daniel Drake <drake@endlessos.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jian-Hong Pan <jhp@endlessos.org>,
	Dieter Mummenschanz <dmummenschanz@web.de>,
	Mario Limonciello <mario.limonciello@amd.com>,
	linux-ide@vger.kernel.org, regressions@lists.linux.dev
Subject: Re: [PATCH v2 2/5] ata: ahci: a hotplug capable port is an external port
Date: Thu, 13 Jun 2024 17:37:51 +0200	[thread overview]
Message-ID: <ZmsST1kF34A9f4-y@ryzen.lan> (raw)
In-Reply-To: <10f95864-3674-4c69-8abf-d4b9f56f9ec4@t-8ch.de>

On Thu, Jun 13, 2024 at 04:49:43PM +0200, Thomas Weißschuh wrote:
> On 2024-06-13 15:38:51+0000, Niklas Cassel wrote:
> > On Thu, Jun 13, 2024 at 03:13:54PM +0200, Niklas Cassel wrote:
> > > On Thu, Jun 13, 2024 at 05:29:31PM +0900, Damien Le Moal wrote:
> > > > On 6/13/24 15:34, Thomas Weißschuh wrote:
> > 
> > > I suggest that we:
> > > 1) Merge Damien's fix.
> > 
> > This might of course result in us getting other bug reports about their
> > distro no longer automounting their eSATA devices... and they might
> > consider that a user space regression as well.
> > (Since that behavior has now been there since 8a3e33cf92c7 ("ata: ahci:
> > find eSATA ports and flag them as removable"), which was merged in 2015.)
> 
> This is quite likely.
> 
> How about reverting the "ata: ahci: a hotplug capable port is an external"
> for now and work on a proper fix, including dev_set_removable() for an
> upcoming release?

Perhaps I'm missing something here, but how will dev_set_removable(),
which sets a different sysfs attibute solve that "problem"?

I think that dev_set_removable() can be added as a follow up patch, since
IIUC it has nothing to do with your bug report.

Calling dev_set_removable(.., DEVICE_REMOVABLE) should simply mean that
the sysfs removable attribute ("fixed"/"removable"/"unknown") will be
correct, so lsblk sees the device as hot-pluggable.
But AFAICT, udisks will not automount the device just because the removable
attribute is set to "removable". You seem to be familiar with udisks,
is this understanding correct?


To be honest, I think that it is wrong to automount devices just because they
are hot-plug capable. eSATA and hot-plug cable ports are according to the
specification both external ports, and eSATA ports are also hot-plug capable.

I guess you could trigger on an uevent if a device is attached after boot,
but automounting a device during boot seems wrong to me.

Regardless, it seems quite clear that the RMB bit should not be set for
neither eSATA nor hot-plug cable ports.


Kind regards,
Niklas

  reply	other threads:[~2024-06-13 15:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-06 21:13 [PATCH v2 0/5] drop low power policy board type Niklas Cassel
2024-02-06 21:13 ` [PATCH v2 1/5] ata: ahci: move marking of external port earlier Niklas Cassel
2024-02-06 21:13 ` [PATCH v2 2/5] ata: ahci: a hotplug capable port is an external port Niklas Cassel
2024-06-13  6:34   ` Thomas Weißschuh
2024-06-13  8:29     ` Damien Le Moal
2024-06-13 12:56       ` Thomas Weißschuh
2024-06-13 13:13       ` Niklas Cassel
2024-06-13 13:38         ` Niklas Cassel
2024-06-13 14:49           ` Thomas Weißschuh
2024-06-13 15:37             ` Niklas Cassel [this message]
2024-06-13 17:33               ` Thomas Weißschuh
2024-06-13 17:54                 ` Niklas Cassel
2024-02-06 21:13 ` [PATCH v2 3/5] ata: ahci: drop hpriv param from ahci_update_initial_lpm_policy() Niklas Cassel
2024-02-07  4:19   ` Jian-Hong Pan
2024-02-06 21:13 ` [PATCH v2 4/5] ata: ahci: do not enable LPM on external ports Niklas Cassel
2024-02-08 23:34   ` Damien Le Moal
2024-02-06 21:13 ` [PATCH v2 5/5] ata: ahci: Drop low power policy board type Niklas Cassel
2024-02-07  4:19   ` Jian-Hong Pan
2024-02-06 21:54 ` [PATCH v2 0/5] drop " Mario Limonciello
2024-02-07  4:30   ` Jian-Hong Pan
2024-02-07  6:35 ` Mika Westerberg
2024-02-08 23:43 ` Damien Le Moal
2024-02-09 10:01 ` Niklas Cassel

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=ZmsST1kF34A9f4-y@ryzen.lan \
    --to=cassel@kernel.org \
    --cc=devlists@wefi.net \
    --cc=dlemoal@kernel.org \
    --cc=dmummenschanz@web.de \
    --cc=drake@endlessos.org \
    --cc=jhp@endlessos.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=mario.limonciello@amd.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox