All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brijesh Singh <brijesh.singh@amd.com>
To: Arnd Bergmann <arnd@arndb.de>, Tejun Heo <tj@kernel.org>
Cc: brijesh.singh@amd.com, linux-kernel@vger.kernel.org,
	hdegoede@redhat.com, linux-ide@vger.kernel.org
Subject: Re: [PATCH v2] ata: add AMD Seattle platform driver
Date: Tue, 26 Jan 2016 10:56:20 -0600	[thread overview]
Message-ID: <56A7A534.6040208@amd.com> (raw)
In-Reply-To: <5730117.gx9ezcyLp7@wuerfel>

Hi Arnd,

On 01/26/2016 06:17 AM, Arnd Bergmann wrote:
> 
> I think it needs more work: The changelog describes it as a normal
> driver, but based on the previous discussion, this is just a hack
> to work around broken BIOS versions that can no longer be fixed in
> the field, and there has not been a decision what the proper
> representation should be in ACPI.
> 
I am not sure if we should label this driver as a hack to workaround the
broken BIOS. Unfortunately SoC did not implemented the enclosure management
per spec. Its not BIOS issue.

> The patch also fails to address the devicetree based case, even though
> we did come to a conclusion that the current behavior is a regression
> (compared to what we had in drivers/ide/) and that there is a relatively
> simple fix to do it right.
> 
I did looked at your recommendation for extending libahci to use ledtrig_ide_activity()
but as I pointed out in previous discussion this function is missing several key features
from EM (enclosure management) pov. e.g missing the slot number, missing the locate and fault led.
In case of EM, each port will have at least three leds (activity, locate and fault). 
Since these LED's are part of EM hence we need to ensure that tools like ledmon and ledctl (which uses libahci sysfs) works well.

The main question is, what is recommended approach to override libachi enclosure managements
transfer led messages function? A platform driver or something else.

Tejun and/or Hans do you have any recommendation ?


- Brijesh

WARNING: multiple messages have this Message-ID (diff)
From: Brijesh Singh <brijesh.singh@amd.com>
To: Arnd Bergmann <arnd@arndb.de>, Tejun Heo <tj@kernel.org>
Cc: <brijesh.singh@amd.com>, <linux-kernel@vger.kernel.org>,
	<hdegoede@redhat.com>, <linux-ide@vger.kernel.org>
Subject: Re: [PATCH v2] ata: add AMD Seattle platform driver
Date: Tue, 26 Jan 2016 10:56:20 -0600	[thread overview]
Message-ID: <56A7A534.6040208@amd.com> (raw)
In-Reply-To: <5730117.gx9ezcyLp7@wuerfel>

Hi Arnd,

On 01/26/2016 06:17 AM, Arnd Bergmann wrote:
> 
> I think it needs more work: The changelog describes it as a normal
> driver, but based on the previous discussion, this is just a hack
> to work around broken BIOS versions that can no longer be fixed in
> the field, and there has not been a decision what the proper
> representation should be in ACPI.
> 
I am not sure if we should label this driver as a hack to workaround the
broken BIOS. Unfortunately SoC did not implemented the enclosure management
per spec. Its not BIOS issue.

> The patch also fails to address the devicetree based case, even though
> we did come to a conclusion that the current behavior is a regression
> (compared to what we had in drivers/ide/) and that there is a relatively
> simple fix to do it right.
> 
I did looked at your recommendation for extending libahci to use ledtrig_ide_activity()
but as I pointed out in previous discussion this function is missing several key features
from EM (enclosure management) pov. e.g missing the slot number, missing the locate and fault led.
In case of EM, each port will have at least three leds (activity, locate and fault). 
Since these LED's are part of EM hence we need to ensure that tools like ledmon and ledctl (which uses libahci sysfs) works well.

The main question is, what is recommended approach to override libachi enclosure managements
transfer led messages function? A platform driver or something else.

Tejun and/or Hans do you have any recommendation ?


- Brijesh

  reply	other threads:[~2016-01-26 16:58 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 16:31 [PATCH v2] ata: add AMD Seattle platform driver Brijesh Singh
2016-01-14 16:31 ` Brijesh Singh
2016-01-20 21:24 ` Brijesh Singh
2016-01-20 21:24   ` Brijesh Singh
2016-01-25 20:43 ` Tejun Heo
2016-01-26  9:36   ` Hans de Goede
2016-03-16 20:12     ` Brijesh Singh
2016-03-16 20:12       ` Brijesh Singh
2016-01-26 12:17   ` Arnd Bergmann
2016-01-26 16:56     ` Brijesh Singh [this message]
2016-01-26 16:56       ` Brijesh Singh
2016-01-29 21:22       ` Arnd Bergmann
2016-01-29 21:31         ` One Thousand Gnomes
2016-02-01 18:56         ` Brijesh Singh
2016-02-01 18:56           ` Brijesh Singh
2016-02-01 20:14           ` Arnd Bergmann
2016-02-01 22:15             ` Brijesh Singh
2016-02-01 22:15               ` Brijesh Singh
2016-02-02 14:08               ` Arnd Bergmann
2016-02-02 18:37                 ` Brijesh Singh
2016-02-02 18:37                   ` Brijesh Singh
2016-02-05 14:50                   ` Arnd Bergmann
2016-02-05 17:23                     ` Brijesh Singh
2016-02-05 17:23                       ` Brijesh Singh
2016-02-08 18:12                       ` Brijesh Singh
2016-02-08 18:12                         ` Brijesh Singh
2016-03-16 21:07             ` Tejun Heo
2016-03-17 17:36               ` Arnd Bergmann
2016-03-18 18:36                 ` Brijesh Singh
2016-03-18 18:36                   ` Brijesh Singh
2016-03-18 20:19                   ` Tejun Heo
2016-04-14  9:08                   ` Matthias Brugger
2016-04-14 22:14                     ` Brijesh Singh
2016-04-14 22:14                       ` Brijesh Singh
2016-04-13 19:15 ` Tejun Heo

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=56A7A534.6040208@amd.com \
    --to=brijesh.singh@amd.com \
    --cc=arnd@arndb.de \
    --cc=hdegoede@redhat.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.