* Re: [PATCH v5] pata_pdc2027x: Fix pdc_adjust_pll() to return the error value
From: Tejun Heo @ 2017-12-11 15:10 UTC (permalink / raw)
To: Arvind Yadav; +Cc: b.zolnierkie, linux-kernel, linux-ide
In-Reply-To: <8a90e02cc2ccca6277702b6b7ec8f5ca1f85ba4d.1512580696.git.arvind.yadav.cs@gmail.com>
On Wed, Dec 06, 2017 at 10:52:54PM +0530, Arvind Yadav wrote:
> This change is to ensure that function pdc_adjust_pll() returns the
> error value to avoid the unnecessary error check for pdc_hardware_init()
> in pdc2027x_reinit_one().
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Doesn't apply on libata/for-4.16.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 3/3] ahci: Allow setting a default LPM policy for mobile chipsets
From: Tejun Heo @ 2017-12-11 14:42 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-ide, linux-kernel
In-Reply-To: <20171206154110.11548-4-hdegoede@redhat.com>
Hello, Hans.
On Wed, Dec 06, 2017 at 04:41:10PM +0100, Hans de Goede wrote:
> CONFIG_SATA_AHCI=y
> +CONFIG_SATA_MOBILE_LPM_POLICY=3
This would change the default behavior. Can we not do that?
Other than that, looks good to me.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 2/3] ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
From: Tejun Heo @ 2017-12-11 14:41 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-ide, linux-kernel
In-Reply-To: <20171206154110.11548-3-hdegoede@redhat.com>
Hello,
On Wed, Dec 06, 2017 at 04:41:09PM +0100, Hans de Goede wrote:
> Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
> SATA controllers. This commit is a preparation patch for allowing a
> different default sata link powermanagement policy for mobile chipsets.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied 1-2 to libata/for-4.16.
Thanks.
--
tejun
^ permalink raw reply
* Re: When will Linux support new RAID controllers
From: Dennis Mungai @ 2017-12-07 14:18 UTC (permalink / raw)
To: Alan Cox
Cc: David F., Christoph Hellwig, linux-raid@vger.kernel.org,
linux-ide, Dan Williams, linux-nvme
In-Reply-To: <20171207141612.2653a0fb@alans-desktop>
Eventually, a driver will roll out. The question is when.
On 7 December 2017 at 17:16, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
> On Mon, 4 Dec 2017 18:01:10 -0800
> "David F." <df7729@gmail.com> wrote:
>
>> Hi,
>>
>> Any word if the patch is available?
>>
>> Is this going mainline anytime soon?
>
> I am not aware of anyone in Intel working on it or planning to work on it
> at this point. Nothing stops someone outside of Intel doing that from the
> code that was released.
>
> For things that need BIOS changes whatever the vendor my experience has
> always been that you make the most impact by talking to the actual system
> vendor (who controls the BIOS), including telling them why you didn't buy
> their machine. At the end of the day businesses make decisions based on
> dollars.
>
> Alan
^ permalink raw reply
* Re: When will Linux support new RAID controllers
From: Alan Cox @ 2017-12-07 14:16 UTC (permalink / raw)
To: David F.
Cc: Dennis Mungai, Christoph Hellwig, linux-raid@vger.kernel.org,
linux-ide, Dan Williams, linux-nvme
In-Reply-To: <CAGRSmLto7dG19zgUkdZjuhacWXo=ju6WdS0YVjC5xOOsGjV9kg@mail.gmail.com>
On Mon, 4 Dec 2017 18:01:10 -0800
"David F." <df7729@gmail.com> wrote:
> Hi,
>
> Any word if the patch is available?
>
> Is this going mainline anytime soon?
I am not aware of anyone in Intel working on it or planning to work on it
at this point. Nothing stops someone outside of Intel doing that from the
code that was released.
For things that need BIOS changes whatever the vendor my experience has
always been that you make the most impact by talking to the actual system
vendor (who controls the BIOS), including telling them why you didn't buy
their machine. At the end of the day businesses make decisions based on
dollars.
Alan
^ permalink raw reply
* Re: When will Linux support new RAID controllers
From: Christoph Hellwig @ 2017-12-07 0:00 UTC (permalink / raw)
To: David F.
Cc: Dennis Mungai, Christoph Hellwig, linux-raid@vger.kernel.org,
linux-ide, Dan Williams, linux-nvme
In-Reply-To: <CAGRSmLto7dG19zgUkdZjuhacWXo=ju6WdS0YVjC5xOOsGjV9kg@mail.gmail.com>
I guess poor Dan got a gag order from the people responsible for this
mess at Intel or something, as he's usually quick to reply and very
helpful.
On Mon, Dec 04, 2017 at 06:01:10PM -0800, David F. wrote:
> Hi,
>
> Any word if the patch is available?
>
> Is this going mainline anytime soon?
>
>
> On Fri, Nov 10, 2017 at 11:06 AM, David F. <df7729@gmail.com> wrote:
> > A patch would be great. There has been several cases where no option
> > to use AHCI mode available, or where a box seller would offer Linux as
> > an alternate boot option against Windows in RAID mode (on the mobo)
> > but could no longer provide Linux with their systems (without
> > additional costs for add-in raid controller).
> >
> > On Fri, Nov 10, 2017 at 5:31 AM, Dennis Mungai <dmngaie@gmail.com> wrote:
> >> That feature would be especially important on systems where the
> >> BIOS/UEFI environment offers no option to toggle back the AHCI mode.
> >> This "RAID" Intel features is also known as "Intel Premium RST mode"
> >> on all current Clevo systems, and on such a platform (the Clevo
> >> P751DM2-G, marketed by the likes of Schenker and Origin PC) is based
> >> on this platform.
> >>
> >> -Dennis.
> >>
> >> On 10 November 2017 at 16:19, Christoph Hellwig <hch@infradead.org> wrote:
> >>> On Thu, Nov 09, 2017 at 10:24:54AM -0800, David F. wrote:
> >>>> It seems that Linux will not see any HD on Intel's 100 Series or newer
> >>>> chipsets (Z170, etc.) when in RAID mode. (typically these systems
> >>>> have M2 NVMe devices ). This is problematic when wanting to use Linux
> >>>> on the system without having to disable RAID and when on their with
> >>>> Windows. Maybe not a linux-raid issue, but is Linux RAID issue
> >>>> within the kernel device support.
> >>>
> >>> Dan (on Cc) posted some patches to support the awkwared so called
> >>> "RAID" mode (it really should be Intel landgrab mode) in the client
> >>> chipsets more than a year ago.
> >>>
> >>> It needed a bit of a rework to be present as a fake PCIe root port
> >>> instead of the platform driver magic, so I wonder what happened to
> >>> it - Dan any chance to get back to it?
> >>>
> >>> _______________________________________________
> >>> Linux-nvme mailing list
> >>> Linux-nvme@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-nvme
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
^ permalink raw reply
* Re: [PATCH] sata: rcar_sata: Reset SATA PHY when Salvator-X board resumes
From: Geert Uytterhoeven @ 2017-12-06 18:56 UTC (permalink / raw)
To: Yoshihiro Kaneko
Cc: linux-ide@vger.kernel.org, Tejun Heo, Simon Horman, Magnus Damm,
Geert Uytterhoeven, Linux-Renesas
In-Reply-To: <1512585925-4251-1-git-send-email-ykaneko0929@gmail.com>
Hi Kaneko-san,
On Wed, Dec 6, 2017 at 7:45 PM, Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
> From: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
>
> Because power of Salvator-X board is cut off in suspend,
> it needs to reset SATA PHY state in resume.
> Otherwise, SATA partition could not be accessed anymore.
Thanks for your patch!
So this is needed on R-Car Gen3 only.
> --- a/drivers/ata/sata_rcar.c
> +++ b/drivers/ata/sata_rcar.c
> @@ -977,11 +977,43 @@ static int sata_rcar_resume(struct device *dev)
> struct sata_rcar_priv *priv = host->private_data;
> void __iomem *base = priv->base;
> int ret;
> + u32 val;
>
> ret = clk_prepare_enable(priv->clk);
> if (ret)
> return ret;
>
> + /* Re-use from sata_rcar_init_controller() */
> + /* reset and setup phy */
> + switch (priv->type) {
> + case RCAR_GEN1_SATA:
> + sata_rcar_gen1_phy_init(priv);
Hence why do this (and the below) on R-Car Gen1, too?
> + break;
> + case RCAR_GEN2_SATA:
> + sata_rcar_gen2_phy_init(priv);
And on both R-Car Gen2 and Gen3 (currently Gen3 is treated like Gen2
everywhere in the driver)?
What about introducing RCAR_GEN3_SATA, and doing the reinit on R-Car Gen3
only?
> + break;
> + default:
> + dev_warn(host->dev, "SATA phy is not initialized\n");
> + break;
> + }
[...]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] sata: rcar_sata: Reset SATA PHY when Salvator-X board resumes
From: Yoshihiro Kaneko @ 2017-12-06 18:45 UTC (permalink / raw)
To: linux-ide
Cc: Tejun Heo, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-renesas-soc
From: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
Because power of Salvator-X board is cut off in suspend,
it needs to reset SATA PHY state in resume.
Otherwise, SATA partition could not be accessed anymore.
Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
Signed-off-by: Hien Dang <hien.dang.eb@rvc.renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
---
This patch is based on the for-next branch of libata tree.
drivers/ata/sata_rcar.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c
index 80ee2f2..aba6121 100644
--- a/drivers/ata/sata_rcar.c
+++ b/drivers/ata/sata_rcar.c
@@ -977,11 +977,43 @@ static int sata_rcar_resume(struct device *dev)
struct sata_rcar_priv *priv = host->private_data;
void __iomem *base = priv->base;
int ret;
+ u32 val;
ret = clk_prepare_enable(priv->clk);
if (ret)
return ret;
+ /* Re-use from sata_rcar_init_controller() */
+ /* reset and setup phy */
+ switch (priv->type) {
+ case RCAR_GEN1_SATA:
+ sata_rcar_gen1_phy_init(priv);
+ break;
+ case RCAR_GEN2_SATA:
+ sata_rcar_gen2_phy_init(priv);
+ break;
+ default:
+ dev_warn(host->dev, "SATA phy is not initialized\n");
+ break;
+ }
+
+ /* SATA-IP reset state */
+ val = ioread32(base + ATAPI_CONTROL1_REG);
+ val |= ATAPI_CONTROL1_RESET;
+ iowrite32(val, base + ATAPI_CONTROL1_REG);
+
+ /* ISM mode, PRD mode, DTEND flag at bit 0 */
+ val = ioread32(base + ATAPI_CONTROL1_REG);
+ val |= ATAPI_CONTROL1_ISM;
+ val |= ATAPI_CONTROL1_DESE;
+ val |= ATAPI_CONTROL1_DTA32M;
+ iowrite32(val, base + ATAPI_CONTROL1_REG);
+
+ /* Release the SATA-IP from the reset state */
+ val = ioread32(base + ATAPI_CONTROL1_REG);
+ val &= ~ATAPI_CONTROL1_RESET;
+ iowrite32(val, base + ATAPI_CONTROL1_REG);
+
/* ack and mask */
iowrite32(0, base + SATAINTSTAT_REG);
iowrite32(0x7ff, base + SATAINTMASK_REG);
--
1.9.1
^ permalink raw reply related
* [PATCH v5] pata_pdc2027x: Fix pdc_adjust_pll() to return the error value
From: Arvind Yadav @ 2017-12-06 17:22 UTC (permalink / raw)
To: b.zolnierkie, tj; +Cc: linux-kernel, linux-ide
This change is to ensure that function pdc_adjust_pll() returns the
error value to avoid the unnecessary error check for pdc_hardware_init()
in pdc2027x_reinit_one().
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2 :
Make function return type 'void' instead of 'int.
Add sapce between ':'.
changes in v3 :
Fix the checkpatch.pl errors in a sperate patch.
changes in v4 :
return the error value from pdc_adjust_pll()
changes in v5 :
remove this empty line (between *return* and }).
drivers/ata/pata_pdc2027x.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/ata/pata_pdc2027x.c b/drivers/ata/pata_pdc2027x.c
index ffd8d33..81f9178 100644
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -515,7 +515,7 @@ static long pdc_read_counter(struct ata_host *host)
* @host: target ATA host
* @pll_clock: The input of PLL in HZ
*/
-static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int board_idx)
+static int pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int board_idx)
{
void __iomem *mmio_base = host->iomap[PDC_MMIO_BAR];
u16 pll_ctl;
@@ -527,7 +527,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
/* Sanity check */
if (unlikely(pll_clock_khz < 5000L || pll_clock_khz > 70000L)) {
printk(KERN_ERR DRV_NAME ": Invalid PLL input clock %ldkHz, give up!\n", pll_clock_khz);
- return;
+ return -EINVAL;
}
#ifdef PDC_DEBUG
@@ -559,7 +559,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
} else {
/* Invalid ratio */
printk(KERN_ERR DRV_NAME ": Invalid ratio %ld, give up!\n", ratio);
- return;
+ return -EINVAL;
}
F = (ratio * (R+2)) / 1000 - 2;
@@ -567,7 +567,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
if (unlikely(F < 0 || F > 127)) {
/* Invalid F */
printk(KERN_ERR DRV_NAME ": F[%d] invalid!\n", F);
- return;
+ return -EINVAL;
}
PDPRINTK("F[%d] R[%d] ratio*1000[%ld]\n", F, R, ratio);
@@ -592,7 +592,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
PDPRINTK("pll_ctl[%X]\n", pll_ctl);
#endif
- return;
+ return 0;
}
/**
@@ -664,9 +664,7 @@ static int pdc_hardware_init(struct ata_host *host, unsigned int board_idx)
dev_info(host->dev, "PLL input clock %ld kHz\n", pll_clock/1000);
/* Adjust PLL control register */
- pdc_adjust_pll(host, pll_clock, board_idx);
-
- return 0;
+ return pdc_adjust_pll(host, pll_clock, board_idx);
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] ahci: Annotate PCI ids for mobile Intel chipsets as such
From: Hans de Goede @ 2017-12-06 15:41 UTC (permalink / raw)
To: Tejun Heo; +Cc: Hans de Goede, linux-ide, linux-kernel
In-Reply-To: <20171206154110.11548-1-hdegoede@redhat.com>
Intel uses different SATA PCI ids for the Desktop and Mobile SKUs of their
chipsets. For older models the comment describing which chipset the PCI id
is for, aksi indicates when we're dealing with a mobile SKU. Extend the
comments for recent chipsets to also indicate mobile SKUs.
The information this commit adds comes from Intel's chipset datasheets.
This commit is a preparation patch for allowing a different default
sata link powermanagement policy for mobile chipsets.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/ata/ahci.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5443cb71d7ba..9d842ff6ec51 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -268,9 +268,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x3b23), board_ahci }, /* PCH AHCI */
{ PCI_VDEVICE(INTEL, 0x3b24), board_ahci }, /* PCH RAID */
{ PCI_VDEVICE(INTEL, 0x3b25), board_ahci }, /* PCH RAID */
- { PCI_VDEVICE(INTEL, 0x3b29), board_ahci }, /* PCH AHCI */
+ { PCI_VDEVICE(INTEL, 0x3b29), board_ahci }, /* PCH M AHCI */
{ PCI_VDEVICE(INTEL, 0x3b2b), board_ahci }, /* PCH RAID */
- { PCI_VDEVICE(INTEL, 0x3b2c), board_ahci }, /* PCH RAID */
+ { PCI_VDEVICE(INTEL, 0x3b2c), board_ahci }, /* PCH M RAID */
{ PCI_VDEVICE(INTEL, 0x3b2f), board_ahci }, /* PCH AHCI */
{ PCI_VDEVICE(INTEL, 0x19b0), board_ahci }, /* DNV AHCI */
{ PCI_VDEVICE(INTEL, 0x19b1), board_ahci }, /* DNV AHCI */
@@ -293,9 +293,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x19cE), board_ahci }, /* DNV AHCI */
{ PCI_VDEVICE(INTEL, 0x19cF), board_ahci }, /* DNV AHCI */
{ PCI_VDEVICE(INTEL, 0x1c02), board_ahci }, /* CPT AHCI */
- { PCI_VDEVICE(INTEL, 0x1c03), board_ahci }, /* CPT AHCI */
+ { PCI_VDEVICE(INTEL, 0x1c03), board_ahci }, /* CPT M AHCI */
{ PCI_VDEVICE(INTEL, 0x1c04), board_ahci }, /* CPT RAID */
- { PCI_VDEVICE(INTEL, 0x1c05), board_ahci }, /* CPT RAID */
+ { PCI_VDEVICE(INTEL, 0x1c05), board_ahci }, /* CPT M RAID */
{ PCI_VDEVICE(INTEL, 0x1c06), board_ahci }, /* CPT RAID */
{ PCI_VDEVICE(INTEL, 0x1c07), board_ahci }, /* CPT RAID */
{ PCI_VDEVICE(INTEL, 0x1d02), board_ahci }, /* PBG AHCI */
@@ -304,20 +304,20 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x2826), board_ahci }, /* PBG RAID */
{ PCI_VDEVICE(INTEL, 0x2323), board_ahci }, /* DH89xxCC AHCI */
{ PCI_VDEVICE(INTEL, 0x1e02), board_ahci }, /* Panther Point AHCI */
- { PCI_VDEVICE(INTEL, 0x1e03), board_ahci }, /* Panther Point AHCI */
+ { PCI_VDEVICE(INTEL, 0x1e03), board_ahci }, /* Panther Point M AHCI */
{ PCI_VDEVICE(INTEL, 0x1e04), board_ahci }, /* Panther Point RAID */
{ PCI_VDEVICE(INTEL, 0x1e05), board_ahci }, /* Panther Point RAID */
{ PCI_VDEVICE(INTEL, 0x1e06), board_ahci }, /* Panther Point RAID */
- { PCI_VDEVICE(INTEL, 0x1e07), board_ahci }, /* Panther Point RAID */
+ { PCI_VDEVICE(INTEL, 0x1e07), board_ahci }, /* Panther Point M RAID */
{ PCI_VDEVICE(INTEL, 0x1e0e), board_ahci }, /* Panther Point RAID */
{ PCI_VDEVICE(INTEL, 0x8c02), board_ahci }, /* Lynx Point AHCI */
- { PCI_VDEVICE(INTEL, 0x8c03), board_ahci }, /* Lynx Point AHCI */
+ { PCI_VDEVICE(INTEL, 0x8c03), board_ahci }, /* Lynx Point M AHCI */
{ PCI_VDEVICE(INTEL, 0x8c04), board_ahci }, /* Lynx Point RAID */
- { PCI_VDEVICE(INTEL, 0x8c05), board_ahci }, /* Lynx Point RAID */
+ { PCI_VDEVICE(INTEL, 0x8c05), board_ahci }, /* Lynx Point M RAID */
{ PCI_VDEVICE(INTEL, 0x8c06), board_ahci }, /* Lynx Point RAID */
- { PCI_VDEVICE(INTEL, 0x8c07), board_ahci }, /* Lynx Point RAID */
+ { PCI_VDEVICE(INTEL, 0x8c07), board_ahci }, /* Lynx Point M RAID */
{ PCI_VDEVICE(INTEL, 0x8c0e), board_ahci }, /* Lynx Point RAID */
- { PCI_VDEVICE(INTEL, 0x8c0f), board_ahci }, /* Lynx Point RAID */
+ { PCI_VDEVICE(INTEL, 0x8c0f), board_ahci }, /* Lynx Point M RAID */
{ PCI_VDEVICE(INTEL, 0x9c02), board_ahci }, /* Lynx Point-LP AHCI */
{ PCI_VDEVICE(INTEL, 0x9c03), board_ahci }, /* Lynx Point-LP AHCI */
{ PCI_VDEVICE(INTEL, 0x9c04), board_ahci }, /* Lynx Point-LP RAID */
@@ -358,21 +358,21 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x9c87), board_ahci }, /* Wildcat Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0x9c8f), board_ahci }, /* Wildcat Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0x8c82), board_ahci }, /* 9 Series AHCI */
- { PCI_VDEVICE(INTEL, 0x8c83), board_ahci }, /* 9 Series AHCI */
+ { PCI_VDEVICE(INTEL, 0x8c83), board_ahci }, /* 9 Series M AHCI */
{ PCI_VDEVICE(INTEL, 0x8c84), board_ahci }, /* 9 Series RAID */
- { PCI_VDEVICE(INTEL, 0x8c85), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x8c85), board_ahci }, /* 9 Series M RAID */
{ PCI_VDEVICE(INTEL, 0x8c86), board_ahci }, /* 9 Series RAID */
- { PCI_VDEVICE(INTEL, 0x8c87), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x8c87), board_ahci }, /* 9 Series M RAID */
{ PCI_VDEVICE(INTEL, 0x8c8e), board_ahci }, /* 9 Series RAID */
- { PCI_VDEVICE(INTEL, 0x8c8f), board_ahci }, /* 9 Series RAID */
+ { PCI_VDEVICE(INTEL, 0x8c8f), board_ahci }, /* 9 Series M RAID */
{ PCI_VDEVICE(INTEL, 0x9d03), board_ahci }, /* Sunrise Point-LP AHCI */
{ PCI_VDEVICE(INTEL, 0x9d05), board_ahci }, /* Sunrise Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0x9d07), board_ahci }, /* Sunrise Point-LP RAID */
{ PCI_VDEVICE(INTEL, 0xa102), board_ahci }, /* Sunrise Point-H AHCI */
- { PCI_VDEVICE(INTEL, 0xa103), board_ahci }, /* Sunrise Point-H AHCI */
+ { PCI_VDEVICE(INTEL, 0xa103), board_ahci }, /* Sunrise Point-H M AHCI */
{ PCI_VDEVICE(INTEL, 0xa105), board_ahci }, /* Sunrise Point-H RAID */
{ PCI_VDEVICE(INTEL, 0xa106), board_ahci }, /* Sunrise Point-H RAID */
- { PCI_VDEVICE(INTEL, 0xa107), board_ahci }, /* Sunrise Point-H RAID */
+ { PCI_VDEVICE(INTEL, 0xa107), board_ahci }, /* Sunrise Point-H M RAID */
{ PCI_VDEVICE(INTEL, 0xa10f), board_ahci }, /* Sunrise Point-H RAID */
{ PCI_VDEVICE(INTEL, 0x2822), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0x2823), board_ahci }, /* Lewisburg AHCI*/
--
2.14.3
^ permalink raw reply related
* [PATCH 0/3] ahci: Allow setting a default LPM policy for mobile chipsets
From: Hans de Goede @ 2017-12-06 15:41 UTC (permalink / raw)
To: Tejun Heo; +Cc: Hans de Goede, linux-ide, linux-kernel
Hi All,
On many laptops setting a different LPM policy then unknown /
max_performance can lead to power-savings of 1.0 - 1.5 Watts (when idle).
Modern ultrabooks idle around 6W (at 50% screen brightness), 1.0 - 1.5W
is a significant chunk of this.
There are some performance / latency costs to enabling LPM by default,
so it is desirable to make it possible to set a different LPM policy
for mobile / laptop variants of chipsets / "South Bridges" vs their
desktop / server counterparts.
This series adds a new ahci.mobile_lpm_policy kernel cmdline option,
which defaults to a new SATA_MOBILE_LPM_POLICY Kconfig option so that
Linux distributions can choose to set a LPM policy for mobile chipsets
by default.
I realize that this series will not be entirely uncontroversial,
enabling LPM by default is not entirely without risk of regressions.
At least min_power is known to cause issues with some disks, including
some reports of data corruption.
But this series only adds a Kconfig option to allow distributions to
select a different LPM policy for mobile chipsets if they which to do so,
the default value is unchanged from before.
I've done a blog-post a while ago to ask users to test this and
specifically the new med_power_with_dipm option which mirrors the
Intel RST Windows drivers defaults:
https://hansdegoede.livejournal.com/18412.html
Test results from this can be found here:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife#How_To_Test
All testing sofar has shown that the med_power_with_dipm option seems to
be safe, even with SSDs which are known to corrupt data with the min_power
setting. Taking this into account, one thing to consider is the following
change to the Kconfig changes in the last patch in the series:
config SATA_MOBILE_LPM_POLICY
int "Default SATA Link Power Management policy for mobile chipsets"
- range 0 4
+ range 0 3
default 0
depends on SATA_AHCI
help
Thus effectively forbidding choosing min_power as default at the Kconfig
level.
Regards,
Hans
^ permalink raw reply
* [PATCH 3/3] ahci: Allow setting a default LPM policy for mobile chipsets
From: Hans de Goede @ 2017-12-06 15:41 UTC (permalink / raw)
To: Tejun Heo; +Cc: Hans de Goede, linux-ide, linux-kernel
In-Reply-To: <20171206154110.11548-1-hdegoede@redhat.com>
On many laptops setting a different LPM policy then unknown /
max_performance can lead to power-savings of 1.0 - 1.5 Watts (when idle).
Modern ultrabooks idle around 6W (at 50% screen brightness), 1.0 - 1.5W
is a significant chunk of this.
There are some performance / latency costs to enabling LPM by default,
so it is desirable to make it possible to set a different LPM policy
for mobile / laptop variants of chipsets / "South Bridges" vs their
desktop / server counterparts. Also enabling LPM by default is not
entirely without risk of regressions. At least min_power is known to
cause issues with some disks, including some reports of data corruption.
This commits adds a new ahci.mobile_lpm_policy kernel cmdline option,
which defaults to a new SATA_MOBILE_LPM_POLICY Kconfig option so that
Linux distributions can choose to set a LPM policy for mobile chipsets
by default.
The reason to have both a kernel cmdline option and a Kconfig default
value for it, is to allow easy overriding of the default to allow
trouble-shooting without needing to rebuild the kernel.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
.config | 1 +
drivers/ata/Kconfig | 19 +++++++++++
drivers/ata/ahci.c | 97 +++++++++++++++++++++++++++++++----------------------
drivers/ata/ahci.h | 3 ++
4 files changed, 79 insertions(+), 41 deletions(-)
diff --git a/.config b/.config
index 758cc273d9da..499dd1fe3cb8 100644
--- a/.config
+++ b/.config
@@ -2283,6 +2283,7 @@ CONFIG_SATA_PMP=y
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=y
+CONFIG_SATA_MOBILE_LPM_POLICY=3
CONFIG_SATA_AHCI_PLATFORM=m
CONFIG_SATA_INIC162X=m
CONFIG_SATA_ACARD_AHCI=m
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index cb5339166563..b3fad5663aeb 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -92,6 +92,25 @@ config SATA_AHCI
If unsure, say N.
+config SATA_MOBILE_LPM_POLICY
+ int "Default SATA Link Power Management policy for mobile chipsets"
+ range 0 4
+ default 0
+ depends on SATA_AHCI
+ help
+ Select the Default SATA Link Power Management (LPM) policy to use
+ for mobile / laptop variants of chipsets / "South Bridges".
+
+ The value set has the following meanings:
+ 0 => Keep firmware settings
+ 1 => Maximum performance
+ 2 => Medium power
+ 3 => Medium power with Device Initiated PM enabled
+ 4 => Minimum power
+
+ Note "Minimum power" is known to cause issues, including disk
+ corruption, with some disks and should not be used.
+
config SATA_AHCI_PLATFORM
tristate "Platform AHCI SATA support"
help
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 844f697bedbf..8e910fae8892 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -65,6 +65,7 @@ enum board_ids {
/* board IDs by feature in alphabetical order */
board_ahci,
board_ahci_ign_iferr,
+ board_ahci_mobile,
board_ahci_nomsi,
board_ahci_noncq,
board_ahci_nosntf,
@@ -140,6 +141,13 @@ static const struct ata_port_info ahci_port_info[] = {
.udma_mask = ATA_UDMA6,
.port_ops = &ahci_ops,
},
+ [board_ahci_mobile] = {
+ AHCI_HFLAGS (AHCI_HFLAG_IS_MOBILE),
+ .flags = AHCI_FLAG_COMMON,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_ops,
+ },
[board_ahci_nomsi] = {
AHCI_HFLAGS (AHCI_HFLAG_NO_MSI),
.flags = AHCI_FLAG_COMMON,
@@ -252,13 +260,13 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x2924), board_ahci }, /* ICH9 */
{ PCI_VDEVICE(INTEL, 0x2925), board_ahci }, /* ICH9 */
{ PCI_VDEVICE(INTEL, 0x2927), board_ahci }, /* ICH9 */
- { PCI_VDEVICE(INTEL, 0x2929), board_ahci }, /* ICH9M */
- { PCI_VDEVICE(INTEL, 0x292a), board_ahci }, /* ICH9M */
- { PCI_VDEVICE(INTEL, 0x292b), board_ahci }, /* ICH9M */
- { PCI_VDEVICE(INTEL, 0x292c), board_ahci }, /* ICH9M */
- { PCI_VDEVICE(INTEL, 0x292f), board_ahci }, /* ICH9M */
+ { PCI_VDEVICE(INTEL, 0x2929), board_ahci_mobile }, /* ICH9M */
+ { PCI_VDEVICE(INTEL, 0x292a), board_ahci_mobile }, /* ICH9M */
+ { PCI_VDEVICE(INTEL, 0x292b), board_ahci_mobile }, /* ICH9M */
+ { PCI_VDEVICE(INTEL, 0x292c), board_ahci_mobile }, /* ICH9M */
+ { PCI_VDEVICE(INTEL, 0x292f), board_ahci_mobile }, /* ICH9M */
{ PCI_VDEVICE(INTEL, 0x294d), board_ahci }, /* ICH9 */
- { PCI_VDEVICE(INTEL, 0x294e), board_ahci }, /* ICH9M */
+ { PCI_VDEVICE(INTEL, 0x294e), board_ahci_mobile }, /* ICH9M */
{ PCI_VDEVICE(INTEL, 0x502a), board_ahci }, /* Tolapai */
{ PCI_VDEVICE(INTEL, 0x502b), board_ahci }, /* Tolapai */
{ PCI_VDEVICE(INTEL, 0x3a05), board_ahci }, /* ICH10 */
@@ -268,9 +276,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x3b23), board_ahci }, /* PCH AHCI */
{ PCI_VDEVICE(INTEL, 0x3b24), board_ahci }, /* PCH RAID */
{ PCI_VDEVICE(INTEL, 0x3b25), board_ahci }, /* PCH RAID */
- { PCI_VDEVICE(INTEL, 0x3b29), board_ahci }, /* PCH M AHCI */
+ { PCI_VDEVICE(INTEL, 0x3b29), board_ahci_mobile }, /* PCH M AHCI */
{ PCI_VDEVICE(INTEL, 0x3b2b), board_ahci }, /* PCH RAID */
- { PCI_VDEVICE(INTEL, 0x3b2c), board_ahci }, /* PCH M RAID */
+ { PCI_VDEVICE(INTEL, 0x3b2c), board_ahci_mobile }, /* PCH M RAID */
{ PCI_VDEVICE(INTEL, 0x3b2f), board_ahci }, /* PCH AHCI */
{ PCI_VDEVICE(INTEL, 0x19b0), board_ahci }, /* DNV AHCI */
{ PCI_VDEVICE(INTEL, 0x19b1), board_ahci }, /* DNV AHCI */
@@ -293,9 +301,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x19cE), board_ahci }, /* DNV AHCI */
{ PCI_VDEVICE(INTEL, 0x19cF), board_ahci }, /* DNV AHCI */
{ PCI_VDEVICE(INTEL, 0x1c02), board_ahci }, /* CPT AHCI */
- { PCI_VDEVICE(INTEL, 0x1c03), board_ahci }, /* CPT M AHCI */
+ { PCI_VDEVICE(INTEL, 0x1c03), board_ahci_mobile }, /* CPT M AHCI */
{ PCI_VDEVICE(INTEL, 0x1c04), board_ahci }, /* CPT RAID */
- { PCI_VDEVICE(INTEL, 0x1c05), board_ahci }, /* CPT M RAID */
+ { PCI_VDEVICE(INTEL, 0x1c05), board_ahci_mobile }, /* CPT M RAID */
{ PCI_VDEVICE(INTEL, 0x1c06), board_ahci }, /* CPT RAID */
{ PCI_VDEVICE(INTEL, 0x1c07), board_ahci }, /* CPT RAID */
{ PCI_VDEVICE(INTEL, 0x1d02), board_ahci }, /* PBG AHCI */
@@ -304,28 +312,28 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x2826), board_ahci }, /* PBG RAID */
{ PCI_VDEVICE(INTEL, 0x2323), board_ahci }, /* DH89xxCC AHCI */
{ PCI_VDEVICE(INTEL, 0x1e02), board_ahci }, /* Panther Point AHCI */
- { PCI_VDEVICE(INTEL, 0x1e03), board_ahci }, /* Panther Point M AHCI */
+ { PCI_VDEVICE(INTEL, 0x1e03), board_ahci_mobile }, /* Panther M AHCI */
{ PCI_VDEVICE(INTEL, 0x1e04), board_ahci }, /* Panther Point RAID */
{ PCI_VDEVICE(INTEL, 0x1e05), board_ahci }, /* Panther Point RAID */
{ PCI_VDEVICE(INTEL, 0x1e06), board_ahci }, /* Panther Point RAID */
- { PCI_VDEVICE(INTEL, 0x1e07), board_ahci }, /* Panther Point M RAID */
+ { PCI_VDEVICE(INTEL, 0x1e07), board_ahci_mobile }, /* Panther M RAID */
{ PCI_VDEVICE(INTEL, 0x1e0e), board_ahci }, /* Panther Point RAID */
{ PCI_VDEVICE(INTEL, 0x8c02), board_ahci }, /* Lynx Point AHCI */
- { PCI_VDEVICE(INTEL, 0x8c03), board_ahci }, /* Lynx Point M AHCI */
+ { PCI_VDEVICE(INTEL, 0x8c03), board_ahci_mobile }, /* Lynx M AHCI */
{ PCI_VDEVICE(INTEL, 0x8c04), board_ahci }, /* Lynx Point RAID */
- { PCI_VDEVICE(INTEL, 0x8c05), board_ahci }, /* Lynx Point M RAID */
+ { PCI_VDEVICE(INTEL, 0x8c05), board_ahci_mobile }, /* Lynx M RAID */
{ PCI_VDEVICE(INTEL, 0x8c06), board_ahci }, /* Lynx Point RAID */
- { PCI_VDEVICE(INTEL, 0x8c07), board_ahci }, /* Lynx Point M RAID */
+ { PCI_VDEVICE(INTEL, 0x8c07), board_ahci_mobile }, /* Lynx M RAID */
{ PCI_VDEVICE(INTEL, 0x8c0e), board_ahci }, /* Lynx Point RAID */
- { PCI_VDEVICE(INTEL, 0x8c0f), board_ahci }, /* Lynx Point M RAID */
- { PCI_VDEVICE(INTEL, 0x9c02), board_ahci }, /* Lynx Point-LP AHCI */
- { PCI_VDEVICE(INTEL, 0x9c03), board_ahci }, /* Lynx Point-LP AHCI */
- { PCI_VDEVICE(INTEL, 0x9c04), board_ahci }, /* Lynx Point-LP RAID */
- { PCI_VDEVICE(INTEL, 0x9c05), board_ahci }, /* Lynx Point-LP RAID */
- { PCI_VDEVICE(INTEL, 0x9c06), board_ahci }, /* Lynx Point-LP RAID */
- { PCI_VDEVICE(INTEL, 0x9c07), board_ahci }, /* Lynx Point-LP RAID */
- { PCI_VDEVICE(INTEL, 0x9c0e), board_ahci }, /* Lynx Point-LP RAID */
- { PCI_VDEVICE(INTEL, 0x9c0f), board_ahci }, /* Lynx Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x8c0f), board_ahci_mobile }, /* Lynx M RAID */
+ { PCI_VDEVICE(INTEL, 0x9c02), board_ahci_mobile }, /* Lynx LP AHCI */
+ { PCI_VDEVICE(INTEL, 0x9c03), board_ahci_mobile }, /* Lynx LP AHCI */
+ { PCI_VDEVICE(INTEL, 0x9c04), board_ahci_mobile }, /* Lynx LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c05), board_ahci_mobile }, /* Lynx LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c06), board_ahci_mobile }, /* Lynx LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c07), board_ahci_mobile }, /* Lynx LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c0e), board_ahci_mobile }, /* Lynx LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c0f), board_ahci_mobile }, /* Lynx LP RAID */
{ PCI_VDEVICE(INTEL, 0x1f22), board_ahci }, /* Avoton AHCI */
{ PCI_VDEVICE(INTEL, 0x1f23), board_ahci }, /* Avoton AHCI */
{ PCI_VDEVICE(INTEL, 0x1f24), board_ahci }, /* Avoton RAID */
@@ -353,26 +361,26 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x8d66), board_ahci }, /* Wellsburg RAID */
{ PCI_VDEVICE(INTEL, 0x8d6e), board_ahci }, /* Wellsburg RAID */
{ PCI_VDEVICE(INTEL, 0x23a3), board_ahci }, /* Coleto Creek AHCI */
- { PCI_VDEVICE(INTEL, 0x9c83), board_ahci }, /* Wildcat Point-LP AHCI */
- { PCI_VDEVICE(INTEL, 0x9c85), board_ahci }, /* Wildcat Point-LP RAID */
- { PCI_VDEVICE(INTEL, 0x9c87), board_ahci }, /* Wildcat Point-LP RAID */
- { PCI_VDEVICE(INTEL, 0x9c8f), board_ahci }, /* Wildcat Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c83), board_ahci_mobile }, /* Wildcat LP AHCI */
+ { PCI_VDEVICE(INTEL, 0x9c85), board_ahci_mobile }, /* Wildcat LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c87), board_ahci_mobile }, /* Wildcat LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9c8f), board_ahci_mobile }, /* Wildcat LP RAID */
{ PCI_VDEVICE(INTEL, 0x8c82), board_ahci }, /* 9 Series AHCI */
- { PCI_VDEVICE(INTEL, 0x8c83), board_ahci }, /* 9 Series M AHCI */
+ { PCI_VDEVICE(INTEL, 0x8c83), board_ahci_mobile }, /* 9 Series M AHCI */
{ PCI_VDEVICE(INTEL, 0x8c84), board_ahci }, /* 9 Series RAID */
- { PCI_VDEVICE(INTEL, 0x8c85), board_ahci }, /* 9 Series M RAID */
+ { PCI_VDEVICE(INTEL, 0x8c85), board_ahci_mobile }, /* 9 Series M RAID */
{ PCI_VDEVICE(INTEL, 0x8c86), board_ahci }, /* 9 Series RAID */
- { PCI_VDEVICE(INTEL, 0x8c87), board_ahci }, /* 9 Series M RAID */
+ { PCI_VDEVICE(INTEL, 0x8c87), board_ahci_mobile }, /* 9 Series M RAID */
{ PCI_VDEVICE(INTEL, 0x8c8e), board_ahci }, /* 9 Series RAID */
- { PCI_VDEVICE(INTEL, 0x8c8f), board_ahci }, /* 9 Series M RAID */
- { PCI_VDEVICE(INTEL, 0x9d03), board_ahci }, /* Sunrise Point-LP AHCI */
- { PCI_VDEVICE(INTEL, 0x9d05), board_ahci }, /* Sunrise Point-LP RAID */
- { PCI_VDEVICE(INTEL, 0x9d07), board_ahci }, /* Sunrise Point-LP RAID */
+ { PCI_VDEVICE(INTEL, 0x8c8f), board_ahci_mobile }, /* 9 Series M RAID */
+ { PCI_VDEVICE(INTEL, 0x9d03), board_ahci_mobile }, /* Sunrise LP AHCI */
+ { PCI_VDEVICE(INTEL, 0x9d05), board_ahci_mobile }, /* Sunrise LP RAID */
+ { PCI_VDEVICE(INTEL, 0x9d07), board_ahci_mobile }, /* Sunrise LP RAID */
{ PCI_VDEVICE(INTEL, 0xa102), board_ahci }, /* Sunrise Point-H AHCI */
- { PCI_VDEVICE(INTEL, 0xa103), board_ahci }, /* Sunrise Point-H M AHCI */
+ { PCI_VDEVICE(INTEL, 0xa103), board_ahci_mobile }, /* Sunrise M AHCI */
{ PCI_VDEVICE(INTEL, 0xa105), board_ahci }, /* Sunrise Point-H RAID */
{ PCI_VDEVICE(INTEL, 0xa106), board_ahci }, /* Sunrise Point-H RAID */
- { PCI_VDEVICE(INTEL, 0xa107), board_ahci }, /* Sunrise Point-H M RAID */
+ { PCI_VDEVICE(INTEL, 0xa107), board_ahci_mobile }, /* Sunrise M RAID */
{ PCI_VDEVICE(INTEL, 0xa10f), board_ahci }, /* Sunrise Point-H RAID */
{ PCI_VDEVICE(INTEL, 0x2822), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0x2823), board_ahci }, /* Lewisburg AHCI*/
@@ -386,10 +394,10 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
- { PCI_VDEVICE(INTEL, 0x0f22), board_ahci }, /* Bay Trail AHCI */
- { PCI_VDEVICE(INTEL, 0x0f23), board_ahci }, /* Bay Trail AHCI */
- { PCI_VDEVICE(INTEL, 0x22a3), board_ahci }, /* Cherry Trail AHCI */
- { PCI_VDEVICE(INTEL, 0x5ae3), board_ahci }, /* Apollo Lake AHCI */
+ { PCI_VDEVICE(INTEL, 0x0f22), board_ahci_mobile }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x0f23), board_ahci_mobile }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x22a3), board_ahci_mobile }, /* Cherry Tr. AHCI */
+ { PCI_VDEVICE(INTEL, 0x5ae3), board_ahci_mobile }, /* ApolloLake AHCI */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
@@ -597,6 +605,9 @@ static int marvell_enable = 1;
module_param(marvell_enable, int, 0644);
MODULE_PARM_DESC(marvell_enable, "Marvell SATA via AHCI (1 = enabled)");
+static int mobile_lpm_policy = CONFIG_SATA_MOBILE_LPM_POLICY;
+module_param(mobile_lpm_policy, int, 0644);
+MODULE_PARM_DESC(mobile_lpm_policy, "Default LPM policy for mobile chipsets");
static void ahci_pci_save_initial_config(struct pci_dev *pdev,
struct ahci_host_priv *hpriv)
@@ -1732,6 +1743,10 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (ap->flags & ATA_FLAG_EM)
ap->em_message_type = hpriv->em_msg_type;
+ if ((hpriv->flags & AHCI_HFLAG_IS_MOBILE) &&
+ mobile_lpm_policy >= ATA_LPM_UNKNOWN &&
+ mobile_lpm_policy <= ATA_LPM_MIN_POWER)
+ ap->target_lpm_policy = mobile_lpm_policy;
/* disabled/not-implemented port */
if (!(hpriv->port_map & (1 << i)))
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 749fd94441b0..a9d996e17d75 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -251,6 +251,9 @@ enum {
AHCI_HFLAG_YES_ALPM = (1 << 23), /* force ALPM cap on */
AHCI_HFLAG_NO_WRITE_TO_RO = (1 << 24), /* don't write to read
only registers */
+ AHCI_HFLAG_IS_MOBILE = (1 << 25), /* mobile chipset, use
+ SATA_MOBILE_LPM_POLICY
+ as default lpm_policy */
/* ap->flags bits */
--
2.14.3
^ permalink raw reply related
* [PATCH 2/3] ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
From: Hans de Goede @ 2017-12-06 15:41 UTC (permalink / raw)
To: Tejun Heo; +Cc: Hans de Goede, linux-ide, linux-kernel
In-Reply-To: <20171206154110.11548-1-hdegoede@redhat.com>
Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
SATA controllers. This commit is a preparation patch for allowing a
different default sata link powermanagement policy for mobile chipsets.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/ata/ahci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 9d842ff6ec51..844f697bedbf 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -386,6 +386,10 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0x0f22), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x0f23), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x22a3), board_ahci }, /* Cherry Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x5ae3), board_ahci }, /* Apollo Lake AHCI */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
--
2.14.3
^ permalink raw reply related
* Re: [PATCH v2] pata_pdc2027x: Fix coding sytle errors
From: Sergei Shtylyov @ 2017-12-06 9:43 UTC (permalink / raw)
To: Arvind Yadav, b.zolnierkie, tj; +Cc: linux-kernel, linux-ide
In-Reply-To: <1512498399-23577-1-git-send-email-arvind.yadav.cs@gmail.com>
On 12/5/2017 9:26 PM, Arvind Yadav wrote:
> Fix these checkpatch.pl errors:
> Fix checkpatch.pl error:
Why repeat it twice?
> ERROR: space prohibited before open square bracket '['.
>
> ERROR: space prohibited after that '~' (ctx:WxW)
> + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA));
>
> ERROR: spaces required around that '?' (ctx:VxW)
> + long pout_required = board_idx? PDC_133_MHZ:PDC_100_MHZ;
>
> ERROR: that open brace { should be on the previous line
> + const struct ata_port_info *ppi[] =
> + { &pdc2027x_port_info[board_idx], NULL };
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> changes in v2:
> Subject and description was not correct.
> *s/sytle error/style errors/ in the patch summary
You didn't really fix the subject. :-/
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v4] pata_pdc2027x: Fix pdc_adjust_pll() to return the error value
From: Sergei Shtylyov @ 2017-12-06 9:41 UTC (permalink / raw)
To: Arvind Yadav, b.zolnierkie, tj; +Cc: linux-kernel, linux-ide
In-Reply-To: <78542c42dcd2f21f6f7c01984061628fb4f19a42.1512499639.git.arvind.yadav.cs@gmail.com>
Hello!
On 12/5/2017 9:50 PM, Arvind Yadav wrote:
> This change is to ensure that function pdc_adjust_pll() returns the
> error value to avoid the unnecessary error check for pdc_hardware_init()
> in pdc2027x_reinit_one().
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> changes in v2 :
> Make function return type 'void' instead of 'int.
> Add sapce between ':'.
> changes in v3 :
> Fix the checkpatch.pl errors in a sperate patch.
> changes in v4 :
> return the error value from pdc_adjust_pll()
>
> drivers/ata/pata_pdc2027x.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/ata/pata_pdc2027x.c b/drivers/ata/pata_pdc2027x.c
> index 82bfd51..eca16b0 100644
> --- a/drivers/ata/pata_pdc2027x.c
> +++ b/drivers/ata/pata_pdc2027x.c
[...]
> @@ -664,9 +664,8 @@ static int pdc_hardware_init(struct ata_host *host, unsigned int board_idx)
> dev_info(host->dev, "PLL input clock %ld kHz\n", pll_clock/1000);
>
> /* Adjust PLL control register */
> - pdc_adjust_pll(host, pll_clock, board_idx);
> + return pdc_adjust_pll(host, pll_clock, board_idx);
>
Please also remove this empty line (between *return* and }).
> - return 0;
> }
>
> /**
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] pata_pdc2027x: Fix coding sytle errors
From: Tejun Heo @ 2017-12-05 19:49 UTC (permalink / raw)
To: Arvind Yadav; +Cc: b.zolnierkie, linux-kernel, linux-ide
In-Reply-To: <1512498399-23577-1-git-send-email-arvind.yadav.cs@gmail.com>
On Tue, Dec 05, 2017 at 11:56:38PM +0530, Arvind Yadav wrote:
> Fix these checkpatch.pl errors:
> Fix checkpatch.pl error:
> ERROR: space prohibited before open square bracket '['.
>
> ERROR: space prohibited after that '~' (ctx:WxW)
> + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA));
>
> ERROR: spaces required around that '?' (ctx:VxW)
> + long pout_required = board_idx? PDC_133_MHZ:PDC_100_MHZ;
>
> ERROR: that open brace { should be on the previous line
> + const struct ata_port_info *ppi[] =
> + { &pdc2027x_port_info[board_idx], NULL };
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Patch doesn't apply to libata/for-4.16. Also, please keep Bart's
Acked-by when posting updated versions.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH v4] pata_pdc2027x: Fix pdc_adjust_pll() to return the error value
From: Arvind Yadav @ 2017-12-05 18:50 UTC (permalink / raw)
To: b.zolnierkie, tj; +Cc: linux-kernel, linux-ide
This change is to ensure that function pdc_adjust_pll() returns the
error value to avoid the unnecessary error check for pdc_hardware_init()
in pdc2027x_reinit_one().
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2 :
Make function return type 'void' instead of 'int.
Add sapce between ':'.
changes in v3 :
Fix the checkpatch.pl errors in a sperate patch.
changes in v4 :
return the error value from pdc_adjust_pll()
drivers/ata/pata_pdc2027x.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/ata/pata_pdc2027x.c b/drivers/ata/pata_pdc2027x.c
index 82bfd51..eca16b0 100644
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -515,7 +515,7 @@ static long pdc_read_counter(struct ata_host *host)
* @host: target ATA host
* @pll_clock: The input of PLL in HZ
*/
-static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int board_idx)
+static int pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int board_idx)
{
void __iomem *mmio_base = host->iomap[PDC_MMIO_BAR];
u16 pll_ctl;
@@ -527,7 +527,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
/* Sanity check */
if (unlikely(pll_clock_khz < 5000L || pll_clock_khz > 70000L)) {
printk(KERN_ERR DRV_NAME ": Invalid PLL input clock %ldkHz, give up!\n", pll_clock_khz);
- return;
+ return -EINVAL;
}
#ifdef PDC_DEBUG
@@ -559,7 +559,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
} else {
/* Invalid ratio */
printk(KERN_ERR DRV_NAME ": Invalid ratio %ld, give up!\n", ratio);
- return;
+ return -EINVAL;
}
F = (ratio * (R+2)) / 1000 - 2;
@@ -567,7 +567,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
if (unlikely(F < 0 || F > 127)) {
/* Invalid F */
printk(KERN_ERR DRV_NAME ": F[%d] invalid!\n", F);
- return;
+ return -EINVAL;
}
PDPRINTK("F[%d] R[%d] ratio*1000[%ld]\n", F, R, ratio);
@@ -592,7 +592,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
PDPRINTK("pll_ctl[%X]\n", pll_ctl);
#endif
- return;
+ return 0;
}
/**
@@ -664,9 +664,8 @@ static int pdc_hardware_init(struct ata_host *host, unsigned int board_idx)
dev_info(host->dev, "PLL input clock %ld kHz\n", pll_clock/1000);
/* Adjust PLL control register */
- pdc_adjust_pll(host, pll_clock, board_idx);
+ return pdc_adjust_pll(host, pll_clock, board_idx);
- return 0;
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH v2] pata_pdc2027x: Fix coding sytle errors
From: Arvind Yadav @ 2017-12-05 18:26 UTC (permalink / raw)
To: b.zolnierkie, tj; +Cc: linux-kernel, linux-ide
Fix these checkpatch.pl errors:
Fix checkpatch.pl error:
ERROR: space prohibited before open square bracket '['.
ERROR: space prohibited after that '~' (ctx:WxW)
+ mask &= ~ (1 << (6 + ATA_SHIFT_UDMA));
ERROR: spaces required around that '?' (ctx:VxW)
+ long pout_required = board_idx? PDC_133_MHZ:PDC_100_MHZ;
ERROR: that open brace { should be on the previous line
+ const struct ata_port_info *ppi[] =
+ { &pdc2027x_port_info[board_idx], NULL };
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
Subject and description was not correct.
*s/sytle error/style errors/ in the patch summary
*s/error/errors/ in the patch description
drivers/ata/pata_pdc2027x.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/ata/pata_pdc2027x.c b/drivers/ata/pata_pdc2027x.c
index 6348a83..d1e8b63 100644
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -84,7 +84,7 @@ static int pdc2027x_set_mode(struct ata_link *link, struct ata_device **r_failed
*/
static struct pdc2027x_pio_timing {
u8 value0, value1, value2;
-} pdc2027x_pio_timing_tbl [] = {
+} pdc2027x_pio_timing_tbl[] = {
{ 0xfb, 0x2b, 0xac }, /* PIO mode 0 */
{ 0x46, 0x29, 0xa4 }, /* PIO mode 1 */
{ 0x23, 0x26, 0x64 }, /* PIO mode 2 */
@@ -94,7 +94,7 @@ static struct pdc2027x_pio_timing {
static struct pdc2027x_mdma_timing {
u8 value0, value1;
-} pdc2027x_mdma_timing_tbl [] = {
+} pdc2027x_mdma_timing_tbl[] = {
{ 0xdf, 0x5f }, /* MDMA mode 0 */
{ 0x6b, 0x27 }, /* MDMA mode 1 */
{ 0x69, 0x25 }, /* MDMA mode 2 */
@@ -102,7 +102,7 @@ static struct pdc2027x_mdma_timing {
static struct pdc2027x_udma_timing {
u8 value0, value1, value2;
-} pdc2027x_udma_timing_tbl [] = {
+} pdc2027x_udma_timing_tbl[] = {
{ 0x4a, 0x0f, 0xd5 }, /* UDMA mode 0 */
{ 0x3a, 0x0a, 0xd0 }, /* UDMA mode 1 */
{ 0x2a, 0x07, 0xcd }, /* UDMA mode 2 */
@@ -277,7 +277,7 @@ static unsigned long pdc2027x_mode_filter(struct ata_device *adev, unsigned long
ATA_ID_PROD_LEN + 1);
/* If the master is a maxtor in UDMA6 then the slave should not use UDMA 6 */
if (strstr(model_num, "Maxtor") == NULL && pair->dma_mode == XFER_UDMA_6)
- mask &= ~ (1 << (6 + ATA_SHIFT_UDMA));
+ mask &= ~(1 << (6 + ATA_SHIFT_UDMA));
return mask;
}
@@ -520,7 +520,7 @@ static void pdc_adjust_pll(struct ata_host *host, long pll_clock, unsigned int b
void __iomem *mmio_base = host->iomap[PDC_MMIO_BAR];
u16 pll_ctl;
long pll_clock_khz = pll_clock / 1000;
- long pout_required = board_idx? PDC_133_MHZ:PDC_100_MHZ;
+ long pout_required = board_idx ? PDC_133_MHZ : PDC_100_MHZ;
long ratio = pout_required / pll_clock_khz;
int F, R;
@@ -705,8 +705,8 @@ static int pdc2027x_init_one(struct pci_dev *pdev,
static const unsigned long cmd_offset[] = { 0x17c0, 0x15c0 };
static const unsigned long bmdma_offset[] = { 0x1000, 0x1008 };
unsigned int board_idx = (unsigned int) ent->driver_data;
- const struct ata_port_info *ppi[] =
- { &pdc2027x_port_info[board_idx], NULL };
+ const struct ata_port_info *ppi[] = {
+ &pdc2027x_port_info[board_idx], NULL };
struct ata_host *host;
void __iomem *mmio_base;
int i, rc;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] pata_pdc2027x: Fix coding sytle error
From: Bartlomiej Zolnierkiewicz @ 2017-12-05 14:12 UTC (permalink / raw)
To: Arvind Yadav; +Cc: tj, sergei.shtylyov, linux-kernel, linux-ide
In-Reply-To: <1823468.mnqCj3ft5Z@amdc3058>
On Tuesday, December 05, 2017 03:02:13 PM Bartlomiej Zolnierkiewicz wrote:
> On Saturday, November 25, 2017 04:04:07 PM Arvind Yadav wrote:
> > Fix these checkpatch.pl error:
> > ERROR: space prohibited before open square bracket '['.
> >
> > ERROR: space prohibited after that '~' (ctx:WxW)
> > + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA));
> >
> > ERROR: spaces required around that '?' (ctx:VxW)
> > + long pout_required = board_idx? PDC_133_MHZ:PDC_100_MHZ;
> >
> > ERROR: that open brace { should be on the previous line
> > + const struct ata_port_info *ppi[] =
> > + { &pdc2027x_port_info[board_idx], NULL };
> >
> > Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
PS two small things than still can be fixed:
* s/sytle error/style errors/ in the patch summary
* s/error/errors/ in the patch description
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH] pata_pdc2027x: Fix coding sytle error
From: Bartlomiej Zolnierkiewicz @ 2017-12-05 14:02 UTC (permalink / raw)
To: Arvind Yadav; +Cc: tj, sergei.shtylyov, linux-kernel, linux-ide
In-Reply-To: <68e25992911d7c4d6c17b9f31524a614466d9588.1511605703.git.arvind.yadav.cs@gmail.com>
On Saturday, November 25, 2017 04:04:07 PM Arvind Yadav wrote:
> Fix these checkpatch.pl error:
> ERROR: space prohibited before open square bracket '['.
>
> ERROR: space prohibited after that '~' (ctx:WxW)
> + mask &= ~ (1 << (6 + ATA_SHIFT_UDMA));
>
> ERROR: spaces required around that '?' (ctx:VxW)
> + long pout_required = board_idx? PDC_133_MHZ:PDC_100_MHZ;
>
> ERROR: that open brace { should be on the previous line
> + const struct ata_port_info *ppi[] =
> + { &pdc2027x_port_info[board_idx], NULL };
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v3] pata_pdc2027x: Remove unnecessary error check
From: Bartlomiej Zolnierkiewicz @ 2017-12-05 13:59 UTC (permalink / raw)
To: Arvind Yadav; +Cc: tj, sergei.shtylyov, linux-kernel, linux-ide
In-Reply-To: <a6bc518e67419242f1409206972590c22f34ba5b.1511604820.git.arvind.yadav.cs@gmail.com>
On Saturday, November 25, 2017 03:49:49 PM Arvind Yadav wrote:
> Here, The function pdc_hardware_init always return zero. So it is not
> necessary to check its return value.
Please fix pdc_adjust_pll() to return the error value instead.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: When will Linux support new RAID controllers
From: David F. @ 2017-12-05 2:01 UTC (permalink / raw)
To: Dennis Mungai
Cc: Christoph Hellwig, linux-raid@vger.kernel.org, linux-ide,
Dan Williams, linux-nvme
In-Reply-To: <CAGRSmLsvAR6wth7tPd5J2kAydy64uQ+h45Yu-SUeOAHkfOHXHA@mail.gmail.com>
Hi,
Any word if the patch is available?
Is this going mainline anytime soon?
On Fri, Nov 10, 2017 at 11:06 AM, David F. <df7729@gmail.com> wrote:
> A patch would be great. There has been several cases where no option
> to use AHCI mode available, or where a box seller would offer Linux as
> an alternate boot option against Windows in RAID mode (on the mobo)
> but could no longer provide Linux with their systems (without
> additional costs for add-in raid controller).
>
> On Fri, Nov 10, 2017 at 5:31 AM, Dennis Mungai <dmngaie@gmail.com> wrote:
>> That feature would be especially important on systems where the
>> BIOS/UEFI environment offers no option to toggle back the AHCI mode.
>> This "RAID" Intel features is also known as "Intel Premium RST mode"
>> on all current Clevo systems, and on such a platform (the Clevo
>> P751DM2-G, marketed by the likes of Schenker and Origin PC) is based
>> on this platform.
>>
>> -Dennis.
>>
>> On 10 November 2017 at 16:19, Christoph Hellwig <hch@infradead.org> wrote:
>>> On Thu, Nov 09, 2017 at 10:24:54AM -0800, David F. wrote:
>>>> It seems that Linux will not see any HD on Intel's 100 Series or newer
>>>> chipsets (Z170, etc.) when in RAID mode. (typically these systems
>>>> have M2 NVMe devices ). This is problematic when wanting to use Linux
>>>> on the system without having to disable RAID and when on their with
>>>> Windows. Maybe not a linux-raid issue, but is Linux RAID issue
>>>> within the kernel device support.
>>>
>>> Dan (on Cc) posted some patches to support the awkwared so called
>>> "RAID" mode (it really should be Intel landgrab mode) in the client
>>> chipsets more than a year ago.
>>>
>>> It needed a bit of a rework to be present as a fake PCIe root port
>>> instead of the platform driver magic, so I wonder what happened to
>>> it - Dan any chance to get back to it?
>>>
>>> _______________________________________________
>>> Linux-nvme mailing list
>>> Linux-nvme@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH] libata: sata_down_spd_limit should return if driver has not recorded sstatus speed
From: Tejun Heo @ 2017-12-04 21:57 UTC (permalink / raw)
To: David Milburn; +Cc: linux-ide
In-Reply-To: <1510697845-58071-1-git-send-email-dmilburn@redhat.com>
On Tue, Nov 14, 2017 at 04:17:25PM -0600, David Milburn wrote:
> During hotplug, it is possible for 6Gbps link speed to
> be limited all the way down to 1.5 Gbps which may lead
> to a slower link speed when drive is re-connected.
>
> This behavior has been seen on a Intel Lewisburg SATA
> controller (8086:a1d2) with HGST HUH728080ALE600 drive
> where SATA link speed was limited to 1.5 Gbps and
> when re-connected the link came up 3.0 Gbps.
>
> This patch was retested on above configuration and
> showed the hotplugged link to come back online at max
> speed (6Gbps). I did not see the downgrade when testing
> on Intel C600/X79, but retested patched linux-4.14-rc5
> kernel and didn't see any side effects from this
> change. Also, successfully retested hotplug on port
> multiplier 3Gbps link.
>
> Signed-off-by: David Milburn <dmilburn@redhat.com>
Applied to libata/for-4.15-fixes.
Thanks.
--
tejun
^ permalink raw reply
* Re: Wiki account on ata.wiki.kernel.org?
From: Tejun Heo @ 2017-12-04 21:00 UTC (permalink / raw)
To: m.wa; +Cc: linux-ide
In-Reply-To: <f2bb97f4-9006-6a38-a8b5-e7f581255d18@uni-muenster.de>
Hello,
On Mon, Dec 04, 2017 at 09:36:46PM +0100, Matthias Peter Walther wrote:
> okay thanks, I guess you've been the one who unlocked my account today.
> So you wouldn't spend the time to update that page?
That wasn't me and no I wouldn't.
> Where is the in-kernel documentation? I'm rather new to this. Is this
> within the kernel's git or where do I find it?
There's driver-api/libata.rst in the source tree but it's also
horribly outdated. If we want up-to-date hardware support
documentation, I think we'd have to move it into the source code and
generate it from there. However, I'm not sure how useful it all
really is. The wiki hasn't been updated for eons, most other
subsystems don't have the counterpart, and not much is really painful
because of that.
But, regardless of what we're gonna do in the long term, if someone is
interested in keeping it fresh, that is really great. The other thing
is that libata development is pretty stale at this point, so maybe we
don't need a grand long term plan and just bringing the wiki
up-to-date is enough.
Thanks.
--
tejun
^ permalink raw reply
* Re: Wiki account on ata.wiki.kernel.org?
From: Matthias Peter Walther @ 2017-12-04 20:36 UTC (permalink / raw)
To: Tejun Heo, m.wa; +Cc: linux-ide
In-Reply-To: <20171204202413.GG2421075@devbig577.frc2.facebook.com>
Hello,
okay thanks, I guess you've been the one who unlocked my account today.
So you wouldn't spend the time to update that page?
Where is the in-kernel documentation? I'm rather new to this. Is this
within the kernel's git or where do I find it?
Regards,
Matthias
Am 04.12.2017 um 21:24 schrieb Tejun Heo:
> On Sat, Dec 02, 2017 at 02:54:42PM +0100, Matthias Peter Walther wrote:
>> Hello,
>>
>> does someone know how to get an account on ata.wiki.kernel.org?
>>
>> I signed up for a new account. But it seems that an administrator needs
>> to unlock it, which has never happened in my case (signed up 22th of
>> November).
> So, I think I still have the admin but the wiki hasn't been updated
> for a long time and is really difficult to keep in sync. I'm not sure
> it's worthwhile to maintain it. The right thing to do probably is
> pulling in whatever relevant information to in-kernel documentation
> and killing the wiki.
>
> Thanks.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox