Re: [PATCH] rtc: x-gene: mark PM functions as __maybe_unused

ed [-Werror=unused-function] > > Just remove the #ifdef and use __maybe_unused annotations instead, > to make the code more robust here. It sounds like desire to merge in the suspend/resume support as this is in linux-next 14 hours ago. Reviewed-by: Loc Ho <l...@apm.com> -Loc

Re: [PATCH] rtc: x-gene: mark PM functions as __maybe_unused

ed [-Werror=unused-function] > > Just remove the #ifdef and use __maybe_unused annotations instead, > to make the code more robust here. It sounds like desire to merge in the suspend/resume support as this is in linux-next 14 hours ago. Reviewed-by: Loc Ho -Loc

[PATCH v6 0/1] acpi: apei: Bug fix to enable APEI support for ARMv8

the driver. Instead, move completely to the FW by accessing the GIC directly. * Fix a bug with function acpi_gsi_to_irq * Enable APEI multiple GHES source to share an single external IRQ v2 * Make all code more generic naming * Still waiting for comment from Linaro folks on APEI --- Loc Ho (1

[PATCH v6 0/1] acpi: apei: Bug fix to enable APEI support for ARMv8

the driver. Instead, move completely to the FW by accessing the GIC directly. * Fix a bug with function acpi_gsi_to_irq * Enable APEI multiple GHES source to share an single external IRQ v2 * Make all code more generic naming * Still waiting for comment from Linaro folks on APEI --- Loc Ho (1

[PATCH v6 1/1] acpi: apei: Enable APEI multiple GHES source to share a single external IRQ

X-Gene platforms describe multiple GHES error sources with the same hardware error notification type (external interrupt) and interrupt number. Change the GHES interrupt request to support sharing the same IRQ. Co-authored-by: Tuan Phan <tp...@apm.com> Signed-off-by: Loc Ho <l..

[PATCH v6 1/1] acpi: apei: Enable APEI multiple GHES source to share a single external IRQ

X-Gene platforms describe multiple GHES error sources with the same hardware error notification type (external interrupt) and interrupt number. Change the GHES interrupt request to support sharing the same IRQ. Co-authored-by: Tuan Phan Signed-off-by: Loc Ho --- drivers/acpi/apei/ghes.c | 3

Re: [PATCH] MAINTAINERS: Fix multiple line section header for XGENE

c > > -EDAC-XGENE > -APPLIED MICRO (APM) X-GENE SOC EDAC > +EDAC-XGENE-APPLIED MICRO (APM) X-GENE SOC EDAC To be consistent with other, how about just: EDAC-XGENE (drop the Applied micro ... line) > M: Loc Ho <l...@apm.com> > S: Supported > F: drivers/edac/xgene_edac.c -Loc

Re: [PATCH] MAINTAINERS: Fix multiple line section header for XGENE

) X-GENE SOC EDAC > +EDAC-XGENE-APPLIED MICRO (APM) X-GENE SOC EDAC To be consistent with other, how about just: EDAC-XGENE (drop the Applied micro ... line) > M: Loc Ho > S: Supported > F: drivers/edac/xgene_edac.c -Loc

[PATCH v5 0/1] acpi: apei: Bug fix to enable APEI support for ARMv8

to the FW by accessing the GIC directly. * Fix a bug with function acpi_gsi_to_irq * Enable APEI multiple GHES source to share an single external IRQ v2 * Make all code more generic naming * Still waiting for comment from Linaro folks on APEI --- Loc Ho (1): acpi: apei: Enable APEI multiple GHES

[PATCH v5 1/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

This patch allows APEI generic error source table with external IRQ to share a single IRQ. Co-authored-by: Tuan Phan <tp...@apm.com> Signed-off-by: Loc Ho <l...@apm.com> --- drivers/acpi/apei/ghes.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/a

[PATCH v5 0/1] acpi: apei: Bug fix to enable APEI support for ARMv8

to the FW by accessing the GIC directly. * Fix a bug with function acpi_gsi_to_irq * Enable APEI multiple GHES source to share an single external IRQ v2 * Make all code more generic naming * Still waiting for comment from Linaro folks on APEI --- Loc Ho (1): acpi: apei: Enable APEI multiple GHES

[PATCH v5 1/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

This patch allows APEI generic error source table with external IRQ to share a single IRQ. Co-authored-by: Tuan Phan Signed-off-by: Loc Ho --- drivers/acpi/apei/ghes.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c

Re: [PATCH 0/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

gt; AFAIR. > > Also, from looking at the patches, the SOB chain is wrong: > > Signed-off-by: Tuan Phan <tp...@apm.com> > Signed-off-by: Loc Ho <l...@apm.com> > > I don't know from that who's the author and who's the submitter. > SubmittingPatches has more info on th

Re: [PATCH 0/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

gt; AFAIR. > > Also, from looking at the patches, the SOB chain is wrong: > > Signed-off-by: Tuan Phan > Signed-off-by: Loc Ho > > I don't know from that who's the author and who's the submitter. > SubmittingPatches has more info on the whole deal. > > So please resubmit

[PATCH v2 1/2] ACPI: SPCR: Use access width to determine mmio usage

. To prevent any legacy issues, the code will default to 8bit accesses if the value is anything but 16 or 32. Signed-off-by: Loc Ho <l...@apm.com> [Re-send as single patch set] Signed-off-by: Jon Mason <jon.ma...@broadcom.com> --- drivers/acpi/spcr.c | 18 --

[PATCH v2 1/2] ACPI: SPCR: Use access width to determine mmio usage

. To prevent any legacy issues, the code will default to 8bit accesses if the value is anything but 16 or 32. Signed-off-by: Loc Ho [Re-send as single patch set] Signed-off-by: Jon Mason --- drivers/acpi/spcr.c | 18 -- include/acpi/acrestyp.h | 7 +++ 2 files changed, 23

[PATCH v2 2/2] ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata

option. Signed-off-by: Loc Ho <l...@apm.com> --- drivers/acpi/spcr.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c index 2905063..4ac3e06 100644 --- a/drivers/acpi/spcr.c +++ b/drivers/acpi/spcr.c @@ -36,6 +36,26 @@ stati

[PATCH v2 0/2] ACPI: SPCR: Use access width to determine mmio usage

v2: * Merged Jon Mason patch with APM X-Gene patch Loc Ho (2): ACPI: SPCR: Use access width to determine mmio usage ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata drivers/acpi/spcr.c | 40 ++-- include/acpi/acrestyp.h | 7

[PATCH v2 0/2] ACPI: SPCR: Use access width to determine mmio usage

v2: * Merged Jon Mason patch with APM X-Gene patch Loc Ho (2): ACPI: SPCR: Use access width to determine mmio usage ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata drivers/acpi/spcr.c | 40 ++-- include/acpi/acrestyp.h | 7

[PATCH v2 2/2] ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata

option. Signed-off-by: Loc Ho --- drivers/acpi/spcr.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c index 2905063..4ac3e06 100644 --- a/drivers/acpi/spcr.c +++ b/drivers/acpi/spcr.c @@ -36,6 +36,26 @@ static bool

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

n the patch you link above would reset it to mmio32. >>>> >> > Personally, I would recommend a big, fat comment on why this extra >>>> >> > step is necessary, but it should work as desired. Alternatively, we >>>> >> > could add some k

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

n the patch you link above would reset it to mmio32. >>>> >> > Personally, I would recommend a big, fat comment on why this extra >>>> >> > step is necessary, but it should work as desired. Alternatively, we >>>> >> > could add some

Re: [PATCH] EDAC: Get rid of mci->mod_ver

Hi, > > any objections? No objection for X-Gene EDAC. -Loc

Re: [PATCH] EDAC: Get rid of mci->mod_ver

Hi, > > any objections? No objection for X-Gene EDAC. -Loc

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

>>> >> > could add some kind of quirk library (similar to >>> >> > qdf2400_erratum_44_present) where the OEM/OEM Table ID is referenced >>> >> > and workaround applied. Thoughts? >>> >> >>> >> That's was my first versio

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

>>> >> > could add some kind of quirk library (similar to >>> >> > qdf2400_erratum_44_present) where the OEM/OEM Table ID is referenced >>> >> > and workaround applied. Thoughts? >>> >> >>> >> That's was my first version b

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

as it works for more SoC's than just our. As > >> you had suggested, we should apply your patch and > >> https://patchwork.kernel.org/patch/9460959. The third patch - > >> https://patchwork.kernel.org/patch/9462183/ - conflicts with your. > >> > >>

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

as it works for more SoC's than just our. As > >> you had suggested, we should apply your patch and > >> https://patchwork.kernel.org/patch/9460959. The third patch - > >> https://patchwork.kernel.org/patch/9462183/ - conflicts with your. > >> > >

Re: [PATCH v2 2/2] i2c: xgene-slimpro: Add ACPI support by using PCC mailbox

Hi Wolfram, >> This patch adds ACPI support by using PCC mailbox communication >> interface. >> >> Signed-off-by: Hoan Tran > > Please make use checkpatch: > > WARNING: braces {} are not necessary for single statement blocks > #149: FILE:

Re: [PATCH v2 2/2] i2c: xgene-slimpro: Add ACPI support by using PCC mailbox

Hi Wolfram, >> This patch adds ACPI support by using PCC mailbox communication >> interface. >> >> Signed-off-by: Hoan Tran > > Please make use checkpatch: > > WARNING: braces {} are not necessary for single statement blocks > #149: FILE: drivers/i2c/busses/i2c-xgene-slimpro.c:242: > + if

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

Hi Jon, > > From: Khuong Dinh > > > > This patch makes pci-xgene-msi driver ACPI-aware and provides > > MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. > > > > Signed-off-by: Khuong Dinh > > Signed-off-by: Duc Dang > > Acked-by:

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

Hi Jon, > > From: Khuong Dinh > > > > This patch makes pci-xgene-msi driver ACPI-aware and provides > > MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. > > > > Signed-off-by: Khuong Dinh > > Signed-off-by: Duc Dang > > Acked-by: Marc Zyngier > > --- > > v2: > > - Verify with

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

t;> 2. Applied this one - https://patchwork.kernel.org/patch/9460959/ >> >> -Loc > > What if we simply applied the following (100% untested) patch to add > the quirk framework I was suggesting? It can be applied on top of the > patch I submitted previously.

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

t;> 2. Applied this one - https://patchwork.kernel.org/patch/9460959/ >> >> -Loc > > What if we simply applied the following (100% untested) patch to add > the quirk framework I was suggesting? It can be applied on top of the > patch I submitted previously. It is a bit

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Hi Jon, On Mon, May 8, 2017 at 1:34 PM, Jon Mason <jon.ma...@broadcom.com> wrote: > On Mon, May 8, 2017 at 3:57 PM, Loc Ho <l...@apm.com> wrote: >> Hi Jon, >> >>>> >>>>>> The current SPCR code does not check the access width of the

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Hi Jon, On Mon, May 8, 2017 at 1:34 PM, Jon Mason wrote: > On Mon, May 8, 2017 at 3:57 PM, Loc Ho wrote: >> Hi Jon, >> >>>> >>>>>> The current SPCR code does not check the access width of the mmio, and >>>>>> uses a default of 8bi

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Hi Jon, >> The current SPCR code does not check the access width of the mmio, and uses a default of 8bit register accesses. This prevents devices that only do 16 or 32bit register accesses from working. By simply checking this field and setting the mmio string appropriately,

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Hi Jon, >> The current SPCR code does not check the access width of the mmio, and uses a default of 8bit register accesses. This prevents devices that only do 16 or 32bit register accesses from working. By simply checking this field and setting the mmio string appropriately,

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Hi Jon, >> The current SPCR code does not check the access width of the mmio, and >> uses a default of 8bit register accesses. This prevents devices that >> only do 16 or 32bit register accesses from working. By simply checking >> this field and setting the mmio string appropriately, this issue

Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Hi Jon, >> The current SPCR code does not check the access width of the mmio, and >> uses a default of 8bit register accesses. This prevents devices that >> only do 16 or 32bit register accesses from working. By simply checking >> this field and setting the mmio string appropriately, this issue

Re: [PATCH] EDAC, xgene: fix spelling mistake: "procesing" -> "processing"

Hi, > > trivial fix to spelling mistake in dev_err message > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Loc Ho <l...@apm.com> > --- > drivers/edac/xgene_edac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > d

Re: [PATCH] EDAC, xgene: fix spelling mistake: "procesing" -> "processing"

Hi, > > trivial fix to spelling mistake in dev_err message > > Signed-off-by: Colin Ian King Reviewed-by: Loc Ho > --- > drivers/edac/xgene_edac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/x

Re: [PATCH] EDAC, xgene: fix spelling mistake in error messages

ac_dev->dev, "IOB PA transaction error\n"); > if (reg & IOBPA_M_TRANS_CORRUPT_MASK) > - dev_err(edac_dev->dev, "Mutilple IOB PA transaction error\n"); > + dev_err(edac_dev->dev, "Multiple IOB PA transaction error\n"); > if (reg & IOBPA_REQIDRAM_CORRUPT_MASK) > dev_err(edac_dev->dev, "IOB PA transaction ID RAM error\n"); > if (reg & IOBPA_M_REQIDRAM_CORRUPT_MASK) Reviewed-by: Loc Ho <l...@apm.com> -Loc

Re: [PATCH] EDAC, xgene: fix spelling mistake in error messages

; > if (reg & IOBPA_M_TRANS_CORRUPT_MASK) > - dev_err(edac_dev->dev, "Mutilple IOB PA transaction error\n"); > + dev_err(edac_dev->dev, "Multiple IOB PA transaction error\n"); > if (reg & IOBPA_REQIDRAM_CORRUPT_MASK) > dev_err(edac_dev->dev, "IOB PA transaction ID RAM error\n"); > if (reg & IOBPA_M_REQIDRAM_CORRUPT_MASK) Reviewed-by: Loc Ho -Loc

Re: [PATCHv2] clk: xgene: Don't call __pa on ioremaped address

gt;param.csr_reg + >>> pclk->param.reg_csr_offset); >>> - pr_debug("%s CSR RESET PADDR base %pa csr offset 0x%08X >>> mask 0x%08X value 0x%08X\n", >>> - clk_hw_get_name(hw), , >>> + pr_debug("%s csr offset 0x%08X mask 0x%08X value >>> 0x%08X\n", >>> + clk_hw_get_name(hw), >>> pclk->param.reg_csr_offset, >>> pclk->param.reg_csr_mask, >>> data); >>> } >> >> >> >> The code looks fine to me. May be overly cautious here. Do you have a >> board to test this out? >> >> -Loc >> > > Yes, that was how I caught the problem. There are no errors that I > can see with this patch applied. Acked-by: Loc Ho <l...@apm.com> -Loc

Re: [PATCHv2] clk: xgene: Don't call __pa on ioremaped address

gt;> pclk->param.reg_csr_offset); >>> - pr_debug("%s CSR RESET PADDR base %pa csr offset 0x%08X >>> mask 0x%08X value 0x%08X\n", >>> - clk_hw_get_name(hw), , >>> + pr_debug("%s csr offset 0x%08X mask 0x%08X value >>> 0x%08X\n", >>> + clk_hw_get_name(hw), >>> pclk->param.reg_csr_offset, >>> pclk->param.reg_csr_mask, >>> data); >>> } >> >> >> >> The code looks fine to me. May be overly cautious here. Do you have a >> board to test this out? >> >> -Loc >> > > Yes, that was how I caught the problem. There are no errors that I > can see with this patch applied. Acked-by: Loc Ho -Loc

Re: [PATCHv2] clk: xgene: Don't call __pa on ioremaped address

Hi Laura, > ioremaped addresses are not linearly mapped so the physical > address can not be figured out via __pa. More generally, there > is no guarantee that backing value of an ioremapped address > is a physical address at all. The value here is only used > for debugging so just drop the call

Re: [PATCHv2] clk: xgene: Don't call __pa on ioremaped address

Hi Laura, > ioremaped addresses are not linearly mapped so the physical > address can not be figured out via __pa. More generally, there > is no guarantee that backing value of an ioremapped address > is a physical address at all. The value here is only used > for debugging so just drop the call

Re: [PATCH 4.4 017/192] [PATCH 017/135] clk: xgene: Fix divider with non-zero shift value

Hi Ben, >> >> -- >> >> >> >> [ Upstream commit 1382ea631b634850a3795527db0feeff5aaf ] >> >> >> >> The X-Gene clock driver missed the divider shift operation when >> >> set the divider value. >> >

Re: [PATCH 4.4 017/192] [PATCH 017/135] clk: xgene: Fix divider with non-zero shift value

Hi Ben, >> >> -- >> >> >> >> [ Upstream commit 1382ea631b634850a3795527db0feeff5aaf ] >> >> >> >> The X-Gene clock driver missed the divider shift operation when >> >> set the divider value. >> >&

Re: [PATCH 4.4 017/192] [PATCH 017/135] clk: xgene: Fix divider with non-zero shift value

Hi, >> 4.4-stable review patch. If anyone has any objections, please let me know. >> >> -- >> >> [ Upstream commit 1382ea631b634850a3795527db0feeff5aaf ] >> >> The X-Gene clock driver missed the divider shift operation when >>

Re: [PATCH 4.4 017/192] [PATCH 017/135] clk: xgene: Fix divider with non-zero shift value

Hi, >> 4.4-stable review patch. If anyone has any objections, please let me know. >> >> -- >> >> [ Upstream commit 1382ea631b634850a3795527db0feeff5aaf ] >> >> The X-Gene clock driver missed the divider shift operation when >>

Re: hwmon: xgene: Add support for X-Gene hwmon driver

Hi Itaru, On Sat, Jul 23, 2016 at 10:04 PM, Itaru Kitayama wrote: > > Hi Hoan, > > I didn't mention in my previous post, though I think I'm using fairly recent > version of Tianocore F/W, and I can confirm there's the PCCT table, > > [0.00] ACPI: PCCT

Re: hwmon: xgene: Add support for X-Gene hwmon driver

Hi Itaru, On Sat, Jul 23, 2016 at 10:04 PM, Itaru Kitayama wrote: > > Hi Hoan, > > I didn't mention in my previous post, though I think I'm using fairly recent > version of Tianocore F/W, and I can confirm there's the PCCT table, > > [0.00] ACPI: PCCT 0x0047FA826000 000300 (v01 APM

Re: [PATCH] phy: xgene: rename "enum phy_mode" to "enum xgene_phy_mode"

ack") > Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com> You can add my: Reviewed-by: Loc Ho <l...@apm.com> -Loc

Re: [PATCH] phy: xgene: rename "enum phy_mode" to "enum xgene_phy_mode"

k") > Signed-off-by: Kishon Vijay Abraham I You can add my: Reviewed-by: Loc Ho -Loc

Re: [PATCH v4] i2c: designware: Do not require clock when SSCN and FFCN are provided

d-off-by: Mika Westerberg >> Signed-off-by: Suravee Suthikulpanit >> Tested-by: Loc Ho >> --- >> >> Note: This has been tested on AMD Seattle RevB for both DT and ACPI. >> >> Changes from V3 (https://lkml.org/lkml/2015/12/22/596): >> * Add i2c

Re: [PATCH v4] i2c: designware: Do not require clock when SSCN and FFCN are provided

t; Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com> >> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> >> Tested-by: Loc Ho <l...@apm.com> >> --- >> >> Note: This has been tested on AMD Seattle RevB for both DT and ACP

Re: [PATCH v4] i2c: designware: Do not require clock when SSCN and FFCN are provided

d-off-by: Mika Westerberg >> Signed-off-by: Suravee Suthikulpanit >> Tested-by: Loc Ho >> --- >> >> Note: This has been tested on AMD Seattle RevB for both DT and ACPI. >> >> Changes from V3 (https://lkml.org/lkml/2015/12/22/596): >> * Add i2c

Re: [PATCH v4] i2c: designware: Do not require clock when SSCN and FFCN are provided

ff-by: Mika Westerberg <mika.westerb...@linux.intel.com> >> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> >> Tested-by: Loc Ho <l...@apm.com> >> --- >> >> Note: This has been tested on AMD Seattle RevB for both DT and ACPI. >>

Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided

Hi, > The current driver uses input clock source frequency to calculate > values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not > currently have a good way to provide the frequency information. > Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used > to

Re: [PATCH] i2c: designware: Do not require clock when SSCN and FFCN are provided

Hi, > The current driver uses input clock source frequency to calculate > values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not > currently have a good way to provide the frequency information. > Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used > to

Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided

Hi, > The current driver uses input clock source frequency to calculate > values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not > currently have a good way to provide the frequency information. > Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used > to

Re: [PATCH] i2c: designware: Do not require clock when SSCN and FFCN are provided

Hi, > The current driver uses input clock source frequency to calculate > values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not > currently have a good way to provide the frequency information. > Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used > to

Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

Hi Murali, >> >> >> Again, there's other SoCs out there which have serdes. Adding 2.5k of >> lines for vendor serdes implementations does not scale - this needs to >> be re-thought in a way which reduces the code maintanence burden. >> >> Other SoCs like Marvell Armada have serdes links which

Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

Hi Murali, >> >> >> Again, there's other SoCs out there which have serdes. Adding 2.5k of >> lines for vendor serdes implementations does not scale - this needs to >> be re-thought in a way which reduces the code maintanence burden. >> >> Other SoCs like Marvell Armada have serdes links which

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

Hi Olof,, >> This patch set adds syscon reboot/poweroff device nodes to support reboot and poweroff features on X-Gene platform. Tai Nguyen (2): power: reset: Add syscon reboot device node for APM X-Gene platform power: reset: Add syscon poweroff device

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

Hi Olof, >> This patch set adds syscon reboot/poweroff device nodes to support reboot and >> poweroff features on X-Gene platform. >> >> Tai Nguyen (2): >> power: reset: Add syscon reboot device node for APM X-Gene platform >> power: reset: Add syscon poweroff device node for APM X-Gene

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

Hi Olof, This patch set adds syscon reboot/poweroff device nodes to support reboot and poweroff features on X-Gene platform. Tai Nguyen (2): power: reset: Add syscon reboot device node for APM X-Gene platform power: reset: Add syscon poweroff device node for APM X-Gene Mustang

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

Hi Olof,, This patch set adds syscon reboot/poweroff device nodes to support reboot and poweroff features on X-Gene platform. Tai Nguyen (2): power: reset: Add syscon reboot device node for APM X-Gene platform power: reset: Add syscon poweroff device node for APM X-Gene Mustang

Re: [Regression] commit 8a4aeec8d(libata/ahci: accommodate tag ordered controllers)

Hi Tejun, >> >> Looks the commit 8a4aeec8d(libata/ahci: accommodate tag ordered >> >> controllers) causes below sata failure[1] on APM AHCI controller. >> >> >> >> And the error does disappear after reverting the commit. >> > >> > Can you give some more details about the workload and the disk?

Re: [Regression] commit 8a4aeec8d(libata/ahci: accommodate tag ordered controllers)

Hi Tejun, Looks the commit 8a4aeec8d(libata/ahci: accommodate tag ordered controllers) causes below sata failure[1] on APM AHCI controller. And the error does disappear after reverting the commit. Can you give some more details about the workload and the disk? What is the APM AHCI?

Re: [GIT PULL] USB patches for 3.15-rc1

pendencies for >>>> this thing. >>>> >>>> It looks like the "select PHY_XGENE" came in through the libata >>>> update, but this USB update actually brought in the "config PHY_XGENE" >>>> and thus this error. Which make

Re: [GIT PULL] USB patches for 3.15-rc1

? Regardless, there's something broken somewhere. Odd, I don't know what to do to fix this up properly. Loc Ho, this came in from your patch, any ideas? Shouldn't we let the users to enable PHY_XGENE (maybe add in the platform defconfig)? This is another option but PHY_XGENE is required

Re: [GIT PULL] USB patches for 3.15-rc1

ta >> update, but this USB update actually brought in the "config PHY_XGENE" >> and thus this error. Which makes me wonder how this all worked. Why >> does that "select PHY_XGENE" exist when apparently it's not needed? >> >> Regardless, there's something bro

Re: [GIT PULL] USB patches for 3.15-rc1

? Regardless, there's something broken somewhere. Odd, I don't know what to do to fix this up properly. Loc Ho, this came in from your patch, any ideas? I don't think it has anything to do with USB. With the current dependency, X-Gene SATA AHCI driver will be included if either ARM64 or COMPILE_TEST

[PATCH v15 3/3] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. The PHY for SATA controller 2 and 3 are enabled by default. Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- arch/arm64/boot/dts/apm-storm.dtsi | 75

[PATCH v15 0/3] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support

override PHY parameter for per controller, per port, and per speed * Patch the generic PHY frame to expose set_speed operation v1 * Initial version Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- Loc Ho (3): Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY

[PATCH v15 1/3] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation

This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation. Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- .../devicetree/bindings/phy/apm-xgene-phy.txt | 79 1 files changed, 79 insertions(+), 0

[PATCH v15 1/3] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation

This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Tuan Phan tp...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- .../devicetree/bindings/phy/apm-xgene-phy.txt | 79

[PATCH v15 0/3] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support

override PHY parameter for per controller, per port, and per speed * Patch the generic PHY frame to expose set_speed operation v1 * Initial version Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Tuan Phan tp...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- Loc Ho (3): Documentation

[PATCH v15 3/3] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. The PHY for SATA controller 2 and 3 are enabled by default. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Tuan Phan tp...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- arch/arm64/boot/dts

[PATCH v14 1/3] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation

This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation. Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- .../devicetree/bindings/phy/apm-xgene-phy.txt | 79 1 files changed, 79 insertions(+), 0

[PATCH v14 3/3] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. The PHY for SATA controller 2 and 3 are enabled by default. Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- arch/arm64/boot/dts/apm-storm.dtsi | 75

[PATCH v14 0/3] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support

the generic PHY frame to expose set_speed operation v1 * Initial version Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- Loc Ho (3): Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation PHY: add APM X-Gene SoC 15Gbps

[PATCH v14 0/3] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support

the generic PHY frame to expose set_speed operation v1 * Initial version Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Tuan Phan tp...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- Loc Ho (3): Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding

[PATCH v14 1/3] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation

This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Tuan Phan tp...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- .../devicetree/bindings/phy/apm-xgene-phy.txt | 79

[PATCH v14 3/3] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. The PHY for SATA controller 2 and 3 are enabled by default. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Tuan Phan tp...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- arch/arm64/boot/dts

[PATCH v13 3/3] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. The PHY for SATA controller 2 and 3 are enabled by default. Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- arch/arm64/boot/dts/apm-storm.dtsi | 75

[PATCH v13 1/3] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation

This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation. Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- .../devicetree/bindings/phy/apm-xgene-phy.txt | 79 1 files changed, 79 insertions(+), 0

[PATCH v13 0/3] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support

requirement based on compatible type * Rename override PHY parameters with more descriptive name * Add override PHY parameter for per controller, per port, and per speed * Patch the generic PHY frame to expose set_speed operation v1 * Initial version Signed-off-by: Loc Ho Signed-off-by: Tuan

Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework

Hi, >> >> This patch adds function set_speed to the generic PHY framework >> >> operation >> >> structure. This function can be called to instruct the PHY >> >> underlying layer >> >> at specified lane to configure for specified speed in hertz. >> > >> > why ?

Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework

Hi, This patch adds function set_speed to the generic PHY framework operation structure. This function can be called to instruct the PHY underlying layer at specified lane to configure for specified speed in hertz. why ? looks like clk_set_rate() is your friend here. Can

[PATCH v13 1/3] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation

This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Tuan Phan tp...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- .../devicetree/bindings/phy/apm-xgene-phy.txt | 79

[PATCH v13 0/3] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support

requirement based on compatible type * Rename override PHY parameters with more descriptive name * Add override PHY parameter for per controller, per port, and per speed * Patch the generic PHY frame to expose set_speed operation v1 * Initial version Signed-off-by: Loc Ho l...@apm.com Signed-off

[PATCH v13 3/3] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. The PHY for SATA controller 2 and 3 are enabled by default. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Tuan Phan tp...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com --- arch/arm64/boot/dts

Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework

Hi Felipe and Kishon, >>> >> >> This patch adds function set_speed to the generic PHY framework >>> >> >> operation >>> >> >> structure. This function can be called to instruct the PHY underlying >>> >> >> layer >>> >> >> at specified lane to configure for specified speed in hertz. >>> >> > >>>

Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework

Hi Felipe and Kishon, This patch adds function set_speed to the generic PHY framework operation structure. This function can be called to instruct the PHY underlying layer at specified lane to configure for specified speed in hertz. why ? looks like clk_set_rate() is your

Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework

HI, >> >> >> This patch adds function set_speed to the generic PHY framework >> >> >> operation >> >> >> structure. This function can be called to instruct the PHY underlying >> >> >> layer >> >> >> at specified lane to configure for specified speed in hertz. >> >> > >> >> > why ? looks like

Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework

Hi, >> >> This patch adds function set_speed to the generic PHY framework operation >> >> structure. This function can be called to instruct the PHY underlying >> >> layer >> >> at specified lane to configure for specified speed in hertz. >> > >> > why ? looks like clk_set_rate() is your friend

  1   2   >