* Re: [PATCH v2 1/3] ARM: pxa: remove Compulab pxa2xx boards
From: Miquel Raynal @ 2020-05-22 13:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mtd, Boris Brezillon, Robert Jarzmik, Linux ARM,
Mike Rapoport
In-Reply-To: <CAK8P3a2Z-UxktGn+_aBVaaBTStT7f177V2ED2RfVCQS8QDBamg@mail.gmail.com>
Hi Arnd,
Arnd Bergmann <arnd@arndb.de> wrote on Fri, 22 May 2020 15:14:43 +0200:
> On Fri, May 22, 2020 at 1:18 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 21 May
> > 2020 21:10:16 +0200:
> >
> > > On Thu, 21 May 2020 22:01:58 +0300
> > > Mike Rapoport <rppt@kernel.org> wrote:
> > >
> > > > On Thu, May 21, 2020 at 09:26:10AM +0200, Arnd Bergmann wrote:
> > > > > On Thu, May 21, 2020 at 9:12 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > > > >
> > > > > > On Wed, May 20, 2020 at 05:21:51PM +0200, Arnd Bergmann wrote:
> > > > > > > On Wed, May 20, 2020 at 12:21 PM Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> > > > > > > >
> > > > > > > > As these boards have no more users nor testers, and patching them has
> > > > > > > > become a burden, be that because of the PCI part or the MTD NAND
> > > > > > > > support, let's remove them.
> > > > > > > >
> > > > > > > > The cm-x300 will for now remain and represent Compulab boards at its
> > > > > > > > best in the PXA department.
> > > > > >
> > > > > > I think this series missed the cm-x270 NAND driver, so this could be
> > > > > > PATCH 4/3 (not even compile tested).
> > > > > >
> > > > > > From 56a11987f82ef8b32b25dfc17b849f9bbbf03e4d Mon Sep 17 00:00:00 2001
> > > > > > From: Mike Rapoport <rppt@linux.ibm.com>
> > > > > > Date: Thu, 21 May 2020 10:09:47 +0300
> > > > > > Subject: [PATCH] mtd: rawnand: remove CM-X270 NAND driver
> > > > > >
> > > > > > The cm-x270 board have been removed and theres is no point to keep this
> > > > > > driver.
> > > > > >
> > > > > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > > > >
> > > > > Thanks! Removing that driver was actually how the discussion started,
> > > > > so we definitely want to do that. Boris earlier patch "mtd: rawnand: Get
> > > > > rid of the cmx270 driver" did it by changing the board file, now your
> > > > > patch is the right thing to do, and we should remember to do the same
> > > > > for mbxfb.
> > > >
> > > > Arnd, will you pick this to the SoC tree or should I resend?
> > >
> > > Actually I sent a v2 removing only the MTD driver. You should probably
> > > sync with Miquel to make sure the same patch is not applied twice.
> >
> > Actually I was about the merge this patch in the MTD tree because I
> > have a big cleanup series which depends on it. Arnd could you confirm
> > that it's okay for you?
>
> Yes, that sounds good. I assume the patch is basically identical to the one
> that Mike just sent, right? If there are changes to arch/arm, I guess those can
> be dropped now as I'm merging Robert's patches to remove those board
> files.
>
> Arnd
Here is the diffstat:
drivers/mtd/nand/raw/Kconfig | 4 -
drivers/mtd/nand/raw/Makefile | 1 -
drivers/mtd/nand/raw/cmx270_nand.c | 236 -----------------------------
3 files changed, 241 deletions(-)
delete mode 100644 drivers/mtd/nand/raw/cmx270_nand.c
So it should be fine.
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: pxa: remove Compulab pxa2xx boards
From: Arnd Bergmann @ 2020-05-22 13:14 UTC (permalink / raw)
To: Miquel Raynal
Cc: linux-mtd, Boris Brezillon, Robert Jarzmik, Linux ARM,
Mike Rapoport
In-Reply-To: <20200522131818.3adbac78@xps13>
On Fri, May 22, 2020 at 1:18 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 21 May
> 2020 21:10:16 +0200:
>
> > On Thu, 21 May 2020 22:01:58 +0300
> > Mike Rapoport <rppt@kernel.org> wrote:
> >
> > > On Thu, May 21, 2020 at 09:26:10AM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 21, 2020 at 9:12 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > > >
> > > > > On Wed, May 20, 2020 at 05:21:51PM +0200, Arnd Bergmann wrote:
> > > > > > On Wed, May 20, 2020 at 12:21 PM Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> > > > > > >
> > > > > > > As these boards have no more users nor testers, and patching them has
> > > > > > > become a burden, be that because of the PCI part or the MTD NAND
> > > > > > > support, let's remove them.
> > > > > > >
> > > > > > > The cm-x300 will for now remain and represent Compulab boards at its
> > > > > > > best in the PXA department.
> > > > >
> > > > > I think this series missed the cm-x270 NAND driver, so this could be
> > > > > PATCH 4/3 (not even compile tested).
> > > > >
> > > > > From 56a11987f82ef8b32b25dfc17b849f9bbbf03e4d Mon Sep 17 00:00:00 2001
> > > > > From: Mike Rapoport <rppt@linux.ibm.com>
> > > > > Date: Thu, 21 May 2020 10:09:47 +0300
> > > > > Subject: [PATCH] mtd: rawnand: remove CM-X270 NAND driver
> > > > >
> > > > > The cm-x270 board have been removed and theres is no point to keep this
> > > > > driver.
> > > > >
> > > > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > > >
> > > > Thanks! Removing that driver was actually how the discussion started,
> > > > so we definitely want to do that. Boris earlier patch "mtd: rawnand: Get
> > > > rid of the cmx270 driver" did it by changing the board file, now your
> > > > patch is the right thing to do, and we should remember to do the same
> > > > for mbxfb.
> > >
> > > Arnd, will you pick this to the SoC tree or should I resend?
> >
> > Actually I sent a v2 removing only the MTD driver. You should probably
> > sync with Miquel to make sure the same patch is not applied twice.
>
> Actually I was about the merge this patch in the MTD tree because I
> have a big cleanup series which depends on it. Arnd could you confirm
> that it's okay for you?
Yes, that sounds good. I assume the patch is basically identical to the one
that Mike just sent, right? If there are changes to arch/arm, I guess those can
be dropped now as I'm merging Robert's patches to remove those board
files.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Mark Brown @ 2020-05-22 13:12 UTC (permalink / raw)
To: Shengjiu Wang
Cc: Sumit Semwal, linaro-mm-sig, Linux-ALSA, linuxppc-dev,
linux-kernel, Timur Tabi, Xiubo Li, shawnguo, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, dri-devel, perex, Nicolin Chen,
linux-imx, kernel, linux-media, Fabio Estevam, s.hauer,
linux-arm-kernel, Lucas Stach
In-Reply-To: <CAA+D8AOiVVi3B4dzU8r=rCMz=6w9R=wxBkzAQ=0=RAQLKCWy8Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 851 bytes --]
On Thu, May 21, 2020 at 07:30:04PM +0800, Shengjiu Wang wrote:
> On Wed, May 20, 2020 at 8:38 PM Mark Brown <broonie@kernel.org> wrote:
> > Other drivers having problems means those drivers should be fixed, not
> > that we should copy the problems. In the case of the PXA driver that's
> > very old code which predates deferred probe by I'd guess a decade.
> Thanks.
> For the FE-BE case, do you have any suggestion for how fix it?
> With DMA1->ASRC->DMA2->ESAI case, the DMA1->ASRC->DMA2
> is in FE, ESAI is in BE. When ESAI drvier probe, DMA3 channel is
> created with ESAI's "dma:tx" (DMA3 channel
> is not used in this FE-BE case). When FE-BE startup, DMA2
> channel is created, it needs the ESAI's "dma:tx", so the warning
> comes out.
Not really TBH, this seems like another one of those csaes where DPCM is
creaking at the seams :/
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v12 03/11] psci: export smccc conduit get helper.
From: Sudeep Holla @ 2020-05-22 13:12 UTC (permalink / raw)
To: Jianyong Wu
Cc: Mark.Rutland, kvm, will, kvmarm, justin.he, Wei.Chen, maz,
steven.price, Kaly.Xin, suzuki.poulose, richardcochran, yangbo.lu,
john.stultz, tglx, nd, linux-arm-kernel, Steve.Capper, netdev,
linux-kernel, sean.j.christopherson, Sudeep Holla, pbonzini
In-Reply-To: <20200522083724.38182-4-jianyong.wu@arm.com>
On Fri, May 22, 2020 at 04:37:16PM +0800, Jianyong Wu wrote:
> Export arm_smccc_1_1_get_conduit then modules can use smccc helper which
> adopts it.
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> ---
> drivers/firmware/psci/psci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 2937d44b5df4..fd3c88f21b6a 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -64,6 +64,7 @@ enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
>
> return psci_ops.conduit;
> }
> +EXPORT_SYMBOL(arm_smccc_1_1_get_conduit);
>
I have moved this into drivers/firmware/smccc/smccc.c [1]
Please update this accordingly.
Also this series is floating on the list for a while now, it is time to
drop "RFC" unless anyone has strong objection to the idea here.
--
Regards,
Sudeep
[1] https://git.kernel.org/arm64/c/f2ae97062a48
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] iio: stm32-dfsdm-adc: keep a reference to the iio device on the state struct
From: Alexandru Ardelean @ 2020-05-22 13:08 UTC (permalink / raw)
To: linux-iio, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Alexandru Ardelean, mcoquelin.stm32, jic23, alexandre.torgue
We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.
Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework.
For this driver, not using iio_priv_to_dev(), means keeping a reference to
the IIO device on the state struct.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/adc/stm32-dfsdm-adc.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index 76a60d93fe23..ff7a6afa4558 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -69,6 +69,7 @@ struct stm32_dfsdm_dev_data {
struct stm32_dfsdm_adc {
struct stm32_dfsdm *dfsdm;
+ struct iio_dev *indio_dev;
const struct stm32_dfsdm_dev_data *dev_data;
unsigned int fl_id;
unsigned int nconv;
@@ -332,7 +333,7 @@ static int stm32_dfsdm_compute_all_osrs(struct iio_dev *indio_dev,
static int stm32_dfsdm_start_channel(struct stm32_dfsdm_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
struct regmap *regmap = adc->dfsdm->regmap;
const struct iio_chan_spec *chan;
unsigned int bit;
@@ -352,7 +353,7 @@ static int stm32_dfsdm_start_channel(struct stm32_dfsdm_adc *adc)
static void stm32_dfsdm_stop_channel(struct stm32_dfsdm_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
struct regmap *regmap = adc->dfsdm->regmap;
const struct iio_chan_spec *chan;
unsigned int bit;
@@ -422,7 +423,7 @@ static int stm32_dfsdm_filter_set_trig(struct stm32_dfsdm_adc *adc,
unsigned int fl_id,
struct iio_trigger *trig)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
struct regmap *regmap = adc->dfsdm->regmap;
u32 jextsel = 0, jexten = STM32_DFSDM_JEXTEN_DISABLED;
int ret;
@@ -451,7 +452,7 @@ static int stm32_dfsdm_channels_configure(struct stm32_dfsdm_adc *adc,
unsigned int fl_id,
struct iio_trigger *trig)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
struct regmap *regmap = adc->dfsdm->regmap;
struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[fl_id];
struct stm32_dfsdm_filter_osr *flo = &fl->flo[0];
@@ -495,7 +496,7 @@ static int stm32_dfsdm_filter_configure(struct stm32_dfsdm_adc *adc,
unsigned int fl_id,
struct iio_trigger *trig)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
struct regmap *regmap = adc->dfsdm->regmap;
struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[fl_id];
struct stm32_dfsdm_filter_osr *flo = &fl->flo[fl->fast];
@@ -1314,7 +1315,7 @@ static const struct iio_info stm32_dfsdm_info_adc = {
static irqreturn_t stm32_dfsdm_irq(int irq, void *arg)
{
struct stm32_dfsdm_adc *adc = arg;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
struct regmap *regmap = adc->dfsdm->regmap;
unsigned int status, int_en;
@@ -1569,6 +1570,7 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
adc = iio_priv(iio);
adc->dfsdm = dev_get_drvdata(dev->parent);
+ adc->indio_dev = iio;
iio->dev.parent = dev;
iio->dev.of_node = np;
@@ -1651,7 +1653,7 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
{
struct stm32_dfsdm_adc *adc = platform_get_drvdata(pdev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
if (adc->dev_data->type == DFSDM_AUDIO)
of_platform_depopulate(&pdev->dev);
@@ -1664,7 +1666,7 @@ static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
static int __maybe_unused stm32_dfsdm_adc_suspend(struct device *dev)
{
struct stm32_dfsdm_adc *adc = dev_get_drvdata(dev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
if (iio_buffer_enabled(indio_dev))
__stm32_dfsdm_predisable(indio_dev);
@@ -1675,7 +1677,7 @@ static int __maybe_unused stm32_dfsdm_adc_suspend(struct device *dev)
static int __maybe_unused stm32_dfsdm_adc_resume(struct device *dev)
{
struct stm32_dfsdm_adc *adc = dev_get_drvdata(dev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
const struct iio_chan_spec *chan;
struct stm32_dfsdm_channel *ch;
int i, ret;
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] iio: stm32-adc: keep a reference to the iio device on the state struct
From: Alexandru Ardelean @ 2020-05-22 13:07 UTC (permalink / raw)
To: linux-iio, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Alexandru Ardelean, mcoquelin.stm32, jic23, alexandre.torgue
We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.
Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework.
For this driver, not using iio_priv_to_dev(), means keeping a reference to
the IIO device on the state struct.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/adc/stm32-adc.c | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
index ae622ee6d08c..7e58c4443e3f 100644
--- a/drivers/iio/adc/stm32-adc.c
+++ b/drivers/iio/adc/stm32-adc.c
@@ -171,6 +171,7 @@ struct stm32_adc_cfg {
/**
* struct stm32_adc - private data of each ADC IIO instance
+ * @indio_dev: back-reference to the IIO device object
* @common: reference to ADC block common data
* @offset: ADC instance register offset in ADC block
* @cfg: compatible configuration data
@@ -194,6 +195,7 @@ struct stm32_adc_cfg {
* @chan_name: channel name array
*/
struct stm32_adc {
+ struct iio_dev *indio_dev;
struct stm32_adc_common *common;
u32 offset;
const struct stm32_adc_cfg *cfg;
@@ -637,7 +639,7 @@ static void stm32h7_adc_start_conv(struct stm32_adc *adc, bool dma)
static void stm32h7_adc_stop_conv(struct stm32_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
int ret;
u32 val;
@@ -654,7 +656,7 @@ static void stm32h7_adc_stop_conv(struct stm32_adc *adc)
static int stm32h7_adc_exit_pwr_down(struct stm32_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
int ret;
u32 val;
@@ -692,7 +694,7 @@ static void stm32h7_adc_enter_pwr_down(struct stm32_adc *adc)
static int stm32h7_adc_enable(struct stm32_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
int ret;
u32 val;
@@ -715,7 +717,7 @@ static int stm32h7_adc_enable(struct stm32_adc *adc)
static void stm32h7_adc_disable(struct stm32_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
int ret;
u32 val;
@@ -735,7 +737,7 @@ static void stm32h7_adc_disable(struct stm32_adc *adc)
*/
static int stm32h7_adc_read_selfcalib(struct stm32_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
int i, ret;
u32 lincalrdyw_mask, val;
@@ -779,7 +781,7 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc *adc)
*/
static int stm32h7_adc_restore_selfcalib(struct stm32_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
int i, ret;
u32 lincalrdyw_mask, val;
@@ -852,7 +854,7 @@ static int stm32h7_adc_restore_selfcalib(struct stm32_adc *adc)
*/
static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
int ret;
u32 val;
@@ -1228,7 +1230,7 @@ static int stm32_adc_read_raw(struct iio_dev *indio_dev,
static irqreturn_t stm32_adc_threaded_isr(int irq, void *data)
{
struct stm32_adc *adc = data;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
const struct stm32_adc_regspec *regs = adc->cfg->regs;
u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg);
@@ -1241,7 +1243,7 @@ static irqreturn_t stm32_adc_threaded_isr(int irq, void *data)
static irqreturn_t stm32_adc_isr(int irq, void *data)
{
struct stm32_adc *adc = data;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
const struct stm32_adc_regspec *regs = adc->cfg->regs;
u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg);
@@ -1879,6 +1881,7 @@ static int stm32_adc_probe(struct platform_device *pdev)
return -ENOMEM;
adc = iio_priv(indio_dev);
+ adc->indio_dev = indio_dev;
adc->common = dev_get_drvdata(pdev->dev.parent);
spin_lock_init(&adc->lock);
init_completion(&adc->completion);
@@ -1990,7 +1993,7 @@ static int stm32_adc_probe(struct platform_device *pdev)
static int stm32_adc_remove(struct platform_device *pdev)
{
struct stm32_adc *adc = platform_get_drvdata(pdev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
pm_runtime_get_sync(&pdev->dev);
iio_device_unregister(indio_dev);
@@ -2013,7 +2016,7 @@ static int stm32_adc_remove(struct platform_device *pdev)
static int stm32_adc_suspend(struct device *dev)
{
struct stm32_adc *adc = dev_get_drvdata(dev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
if (iio_buffer_enabled(indio_dev))
__stm32_adc_buffer_predisable(indio_dev);
@@ -2024,7 +2027,7 @@ static int stm32_adc_suspend(struct device *dev)
static int stm32_adc_resume(struct device *dev)
{
struct stm32_adc *adc = dev_get_drvdata(dev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = adc->indio_dev;
int ret;
ret = pm_runtime_force_resume(dev);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] iommu: Fix group refcount in iommu_alloc_default_domain()
From: Sai Prakash Ranjan @ 2020-05-22 13:01 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Joerg Roedel
Cc: Sai Prakash Ranjan, linux-arm-msm, linux-kernel, Evan Green,
Douglas Anderson, iommu, linux-arm-kernel
Since the change to move default domain allocation to probe,
there is a refcount decrement missing for the group in
iommu_alloc_default_domain(). Because of this missing
refcount decrement, the device is never released from the
group as the devices_kobj refcount never reaches 0 in
iommu_group_remove_device() leading to a lot of issues.
One such case is that this will lead to a different group
allocation on every reload of the module which configures
iommu such as the ath10k module which then finally fails
to attach this device to the SMMU with -ENOSPC error in
__arm_smmu_alloc_bitmap() once the count of module reload
crosses the number of context banks. This will then lead
to NULL pointer deference in the next reload of the module.
Add the missing refcount decrement(iommu_group_put()) in
iommu_alloc_default_domain() to fix this issue.
Call trace:
<snip>...
platform wifi-firmware.0: Adding to iommu group 82
ath10k_snoc 18800000.wifi: could not attach device: -28
platform wifi-firmware.0: Removing from iommu group 82
ath10k_snoc 18800000.wifi: failed to initialize firmware: -28
ath10k_snoc: probe of 18800000.wifi failed with error -28
platform wifi-firmware.0: Adding to iommu group 83
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
ESR = 0x96000006
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000006
CM = 0, WnR = 0
user pgtable: 4k pages, 39-bit VAs, pgdp=0000000177a53000
[0000000000000000] pgd=00000001e74f5003, pud=00000001e74f5003, pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
pstate: 60400009 (nZCv daif +PAN -UAO)
arm_smmu_flush_iotlb_all+0x20/0x6c
iommu_create_device_direct_mappings+0x17c/0x1d8
iommu_probe_device+0xc0/0x100
of_iommu_configure+0x108/0x240
of_dma_configure+0x130/0x1d0
ath10k_fw_init+0xc4/0x1c4 [ath10k_snoc]
ath10k_snoc_probe+0x5cc/0x678 [ath10k_snoc]
platform_drv_probe+0x90/0xb0
really_probe+0x134/0x2ec
driver_probe_device+0x64/0xfc
device_driver_attach+0x4c/0x6c
__driver_attach+0xac/0xc0
bus_for_each_dev+0x8c/0xd4
driver_attach+0x2c/0x38
bus_add_driver+0xfc/0x1d0
driver_register+0x64/0xf8
__platform_driver_register+0x4c/0x58
init_module+0x20/0x1000 [ath10k_snoc]
do_one_initcall+0x13c/0x2d0
do_init_module+0x58/0x1dc
load_module+0xde0/0xf10
__arm64_sys_finit_module+0xb0/0xe0
el0_svc_common+0xa4/0x154
el0_svc_compat_handler+0x2c/0x38
el0_svc_compat+0x8/0x10
Code: d503201f f85b8268 b4000248 f8560e74 (f9400280)
---[ end trace e5c1470a584952a0 ]---
Kernel panic - not syncing: Fatal exception
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
drivers/iommu/iommu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index a4c2f122eb8b..05f7b77c432f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1491,6 +1491,7 @@ static int iommu_alloc_default_domain(struct device *dev)
{
struct iommu_group *group;
unsigned int type;
+ int ret;
group = iommu_group_get(dev);
if (!group)
@@ -1501,7 +1502,11 @@ static int iommu_alloc_default_domain(struct device *dev)
type = iommu_get_def_domain_type(dev);
- return iommu_group_alloc_default_domain(dev->bus, group, type);
+ ret = iommu_group_alloc_default_domain(dev->bus, group, type);
+
+ iommu_group_put(group);
+
+ return ret;
}
/**
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v7 00/15] Add support for devices in the Energy Model
From: Daniel Lezcano @ 2020-05-22 13:01 UTC (permalink / raw)
To: Lukasz Luba, linux-kernel, linux-pm, linux-arm-kernel, dri-devel,
linux-omap, linux-mediatek, linux-arm-msm, linux-imx
Cc: nm, juri.lelli, peterz, viresh.kumar, liviu.dudau,
bjorn.andersson, bsegall, festevam, mka, robh, amit.kucheria,
lorenzo.pieralisi, khilman, steven.price, cw00.choi, mingo,
mgorman, rui.zhang, alyssa.rosenzweig, orjan.eide, daniel,
b.zolnierkie, s.hauer, rostedt, matthias.bgg, Dietmar.Eggemann,
airlied, tomeu.vizoso, qperret, sboyd, rdunlap, rjw, agross,
kernel, sudeep.holla, patrick.bellasi, shawnguo
In-Reply-To: <3f6652a5-ad9b-15cb-08a8-160becd3f912@arm.com>
On 22/05/2020 14:58, Lukasz Luba wrote:
[ ... ]
>>>
>>> The patch set is based on linux-next tag next-20200508.
>>
>> Do you think it is possible to respin against linux-pm next ?
>
> Yes, I will do it and send the v8.
>
>>
>> I wanted to try the series but I'm getting non trivial conflicts with
>> the devfreq_cooling changes
>>
>>
>
> Let me take care of this.
Thanks Lukasz !
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PM / devfreq: fix odd_ptr_err.cocci warnings
From: Julia Lawall @ 2020-05-22 12:59 UTC (permalink / raw)
To: kbuild-all, Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Rob Herring, Mark Rutland, Matthias Brugger,
Rafael J . Wysocki, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Liam Girdwood, Mark Brown, devicetree, Andrew-sh . Cheng,
srv_heupstream, linux-pm, linux-kernel, Saravana Kannan,
linux-mediatek, Sibi Sankar, linux-arm-kernel
In-Reply-To: <20200521160908.GA88022@052716d1a29e>
Hello,
This provides a patch, but it doesn't look like the right one. It looks
like the if test should be testing opp_table,
julia
On Fri, 22 May 2020, kbuild test robot wrote:
> From: kbuild test robot <lkp@intel.com>
>
> drivers/devfreq/governor_passive.c:336:7-13: inconsistent IS_ERR and PTR_ERR on line 337.
>
> PTR_ERR should access the value just tested by IS_ERR
>
> Semantic patch information:
> There can be false positives in the patch case, where it is the call to
> IS_ERR that is wrong.
>
> Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
>
> CC: Saravana Kannan <skannan@codeaurora.org>
> Signed-off-by: kbuild test robot <lkp@intel.com>
> ---
>
> url: https://github.com/0day-ci/linux/commits/Andrew-sh-Cheng/Add-cpufreq-and-cci-devfreq-for-mt8183-and-SVS-support/20200520-222709
> base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
> :::::: branch date: 26 hours ago
> :::::: commit date: 26 hours ago
>
> Please take the patch only if it's a positive warning. Thanks!
>
> governor_passive.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -334,7 +334,7 @@ static int cpufreq_passive_register(stru
>
> opp_table = dev_pm_opp_get_opp_table(cpu_dev);
> if (IS_ERR(devfreq->opp_table)) {
> - ret = PTR_ERR(opp_table);
> + ret = PTR_ERR(devfreq->opp_table);
> goto out;
> }
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 00/15] Add support for devices in the Energy Model
From: Lukasz Luba @ 2020-05-22 12:58 UTC (permalink / raw)
To: Daniel Lezcano, linux-kernel, linux-pm, linux-arm-kernel,
dri-devel, linux-omap, linux-mediatek, linux-arm-msm, linux-imx
Cc: nm, juri.lelli, peterz, viresh.kumar, liviu.dudau,
bjorn.andersson, bsegall, festevam, mka, robh, amit.kucheria,
lorenzo.pieralisi, khilman, steven.price, cw00.choi, mingo,
mgorman, rui.zhang, alyssa.rosenzweig, orjan.eide, daniel,
b.zolnierkie, s.hauer, rostedt, matthias.bgg, Dietmar.Eggemann,
airlied, tomeu.vizoso, qperret, sboyd, rdunlap, rjw, agross,
kernel, sudeep.holla, patrick.bellasi, shawnguo
In-Reply-To: <abff69b6-b033-18e2-f380-ceccb42c6b01@linaro.org>
Hi Daniel,
On 5/22/20 11:43 AM, Daniel Lezcano wrote:
>
> Hi Lukasz,
>
> On 11/05/2020 13:18, Lukasz Luba wrote:
>> Hi all,
>>
>> This patch set introduces support for devices in the Energy Model (EM)
>> framework. It will unify the power model for thermal subsystem. It will
>> make simpler to add support for new devices willing to use more
>> advanced features (like Intelligent Power Allocation). Now it should
>> require less knowledge and effort for driver developer to add e.g.
>> GPU driver with simple energy model. A more sophisticated energy model
>> in the thermal framework is also possible, driver needs to provide
>> a dedicated callback function. More information can be found in the
>> updated documentation file.
>>
>> First 7 patches are refactoring Energy Model framework to add support
>> of other devices that CPUs. They change:
>> - naming convention from 'capacity' to 'performance' state,
>> - API arguments adding device pointer and not rely only on cpumask,
>> - change naming when 'cpu' was used, now it's a 'device'
>> - internal structure to maintain registered devices
>> - update users to the new API
>> Patch 8 updates OPP framework helper function to be more generic, not
>> CPU specific.
>> Patches 9-14 change devfreq cooling, dropping part of old power model and
>> adding registration with Energy Model via exported GPL function.
>> The last path is a simple change for Panfrost GPU driver.
>>
>> The patch set is based on linux-next tag next-20200508.
>
> Do you think it is possible to respin against linux-pm next ?
Yes, I will do it and send the v8.
>
> I wanted to try the series but I'm getting non trivial conflicts with
> the devfreq_cooling changes
>
>
Let me take care of this.
Regards,
Lukasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 39/38] drm: xen: fix common struct sg_table related issues
From: Marek Szyprowski @ 2020-05-22 12:56 UTC (permalink / raw)
To: dri-devel, iommu, linaro-mm-sig, linux-kernel
Cc: Bartlomiej Zolnierkiewicz, David Airlie, Oleksandr Andrushchenko,
Daniel Vetter, xen-devel, Robin Murphy, Christoph Hellwig,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20200513132114.6046-1-m.szyprowski@samsung.com>
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().
struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).
It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.
Fix the code to refer to proper nents or orig_nents entries. This driver
reports the number of the pages in the imported scatterlist, so it should
refer to sg_table->orig_nents entry.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@samsung.com/T/
This patch has been resurrected on Oleksandr Andrushchenko request. The
patch was a part of v2 patchset, but then I've dropped it as it only
fixes the debug output, thus I didn't consider it so critical.
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e0..ba4bdc5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -215,7 +215,7 @@ struct drm_gem_object *
return ERR_PTR(ret);
DRM_DEBUG("Imported buffer of size %zu with nents %u\n",
- size, sgt->nents);
+ size, sgt->orig_nents);
return &xen_obj->base;
}
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] base: soc: Add JEDEC JEP106 manufacturer's identification code attribute
From: Sudeep Holla @ 2020-05-22 12:49 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann,
Greg Kroah-Hartman, linux-kernel, harb, Sudeep Holla, Will Deacon
In-Reply-To: <20200522124951.35776-1-sudeep.holla@arm.com>
SMCCC v1.2 adds a new optional function SMCCC_ARCH_SOC_ID to obtain a
SiP defined SoC identification value. Indeed of making it custom
attribute, let us add the same as generic attribute to soc_device.
There are various ways in which it can be represented in shortened form
for efficiency and ease of parsing for userspace. The chosen form is
described in the ABI document.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
Documentation/ABI/testing/sysfs-devices-soc | 31 +++++++++++++++++++++
drivers/base/soc.c | 12 ++++++++
include/linux/sys_soc.h | 1 +
3 files changed, 44 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc
index ba3a3fac0ee1..fd44c9b1e09a 100644
--- a/Documentation/ABI/testing/sysfs-devices-soc
+++ b/Documentation/ABI/testing/sysfs-devices-soc
@@ -54,6 +54,37 @@ contact: Lee Jones <lee.jones@linaro.org>
Read-only attribute supported ST-Ericsson's silicon. Contains the
the process by which the silicon chip was manufactured.
+What: /sys/devices/socX/jep106_identification_code
+Date: June 2020
+Contact: Sudeep Holla <sudeep.holla@arm.com>
+Description:
+ Read-only attribute supported on many of ARM based silicon
+ with SMCCC v1.2+ compliant firmware. Contains the JEDEC
+ JEP106 manufacturer’s identification code.
+
+ This manufacturer’s identification code is defined by one
+ or more eight (8) bit fields, each consisting of seven (7)
+ data bits plus one (1) odd parity bit. It is a single field,
+ limiting the possible number of vendors to 126. To expand
+ the maximum number of identification codes, a continuation
+ scheme has been defined.
+
+ The specified mechanism is that an identity code of 0x7F
+ represents the "continuation code" and implies the presence
+ of an additional identity code field, and this mechanism
+ may be extended to multiple continuation codes followed
+ by the manufacturer's identity code.
+
+ For example, ARM has identity code 0x7F 0x7F 0x7F 0x7F 0x3B,
+ which is code 0x3B on the fifth 'page'. This can be shortened
+ as JEP106 identity code of 0x3B and a continuation code of
+ 0x4 to represent the four continuation codes preceding the
+ identity code.
+
+ This property represents it in the shortened form:
+ 8-bit continuation code followed by 8 bit identity code
+ without the parity bit.
+
What: /sys/bus/soc
Date: January 2012
contact: Lee Jones <lee.jones@linaro.org>
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 4af11a423475..44dc757aadf4 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -36,6 +36,7 @@ static DEVICE_ATTR(family, S_IRUGO, soc_info_get, NULL);
static DEVICE_ATTR(serial_number, S_IRUGO, soc_info_get, NULL);
static DEVICE_ATTR(soc_id, S_IRUGO, soc_info_get, NULL);
static DEVICE_ATTR(revision, S_IRUGO, soc_info_get, NULL);
+static DEVICE_ATTR(jep106_identification_code, S_IRUGO, soc_info_get, NULL);
struct device *soc_device_to_device(struct soc_device *soc_dev)
{
@@ -64,6 +65,9 @@ static umode_t soc_attribute_mode(struct kobject *kobj,
if ((attr == &dev_attr_soc_id.attr)
&& (soc_dev->attr->soc_id != NULL))
return attr->mode;
+ if ((attr == &dev_attr_jep106_identification_code.attr)
+ && (soc_dev->attr->jep106_id != NULL))
+ return attr->mode;
/* Unknown or unfilled attribute. */
return 0;
@@ -85,6 +89,8 @@ static ssize_t soc_info_get(struct device *dev,
return sprintf(buf, "%s\n", soc_dev->attr->serial_number);
if (attr == &dev_attr_soc_id)
return sprintf(buf, "%s\n", soc_dev->attr->soc_id);
+ if (attr == &dev_attr_jep106_identification_code)
+ return sprintf(buf, "%s\n", soc_dev->attr->jep106_id);
return -EINVAL;
@@ -96,6 +102,7 @@ static struct attribute *soc_attr[] = {
&dev_attr_serial_number.attr,
&dev_attr_soc_id.attr,
&dev_attr_revision.attr,
+ &dev_attr_jep106_identification_code.attr,
NULL,
};
@@ -214,6 +221,11 @@ static int soc_device_match_attr(const struct soc_device_attribute *attr,
(!attr->soc_id || !glob_match(match->soc_id, attr->soc_id)))
return 0;
+ if (match->jep106_id &&
+ (!attr->jep106_id ||
+ !glob_match(match->jep106_id, attr->jep106_id)))
+ return 0;
+
return 1;
}
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index d9b3cf0f410c..394fa70ae16f 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -14,6 +14,7 @@ struct soc_device_attribute {
const char *revision;
const char *serial_number;
const char *soc_id;
+ const char *jep106_id;
const void *data;
const struct attribute_group *custom_attr_group;
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] firmware: smccc: Add ARCH_SOC_ID support
From: Sudeep Holla @ 2020-05-22 12:49 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann,
Greg Kroah-Hartman, linux-kernel, harb, Sudeep Holla, Will Deacon
In-Reply-To: <20200522124951.35776-1-sudeep.holla@arm.com>
SMCCC v1.2 adds a new optional function SMCCC_ARCH_SOC_ID to obtain a
SiP defined SoC identification value. Add support for the same.
Also using the SoC bus infrastructure, let us expose the platform
specific SoC atrributes under sysfs.
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Etienne Carriere <etienne.carriere@st.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/smccc/Kconfig | 9 +++
drivers/firmware/smccc/Makefile | 1 +
drivers/firmware/smccc/soc_id.c | 113 ++++++++++++++++++++++++++++++++
include/linux/arm-smccc.h | 5 ++
4 files changed, 128 insertions(+)
create mode 100644 drivers/firmware/smccc/soc_id.c
diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
index 27b675d76235..15e7466179a6 100644
--- a/drivers/firmware/smccc/Kconfig
+++ b/drivers/firmware/smccc/Kconfig
@@ -14,3 +14,12 @@ config HAVE_ARM_SMCCC_DISCOVERY
to add SMCCC discovery mechanism though the PSCI firmware
implementation of PSCI_FEATURES(SMCCC_VERSION) which returns
success on firmware compliant to SMCCC v1.1 and above.
+
+config ARM_SMCCC_SOC_ID
+ bool "SoC bus device for the ARM SMCCC SOC_ID"
+ depends on HAVE_ARM_SMCCC_DISCOVERY
+ default y
+ select SOC_BUS
+ help
+ Include support for the SoC bus on the ARM SMCCC firmware based
+ platforms providing some sysfs information about the SoC variant.
diff --git a/drivers/firmware/smccc/Makefile b/drivers/firmware/smccc/Makefile
index 6f369fe3f0b9..72ab84042832 100644
--- a/drivers/firmware/smccc/Makefile
+++ b/drivers/firmware/smccc/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
#
obj-$(CONFIG_HAVE_ARM_SMCCC_DISCOVERY) += smccc.o
+obj-$(CONFIG_ARM_SMCCC_SOC_ID) += soc_id.o
diff --git a/drivers/firmware/smccc/soc_id.c b/drivers/firmware/smccc/soc_id.c
new file mode 100644
index 000000000000..437175a589e2
--- /dev/null
+++ b/drivers/firmware/smccc/soc_id.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Arm Limited
+ */
+
+#define pr_fmt(fmt) "SMCCC: SOC_ID: " fmt
+
+#include <linux/arm-smccc.h>
+#include <linux/bitfield.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+
+#define SMCCC_SOC_ID_JEP106_BANK_IDX_MASK GENMASK(30, 24)
+/*
+ * As per the SMC Calling Convention specification v1.2 (ARM DEN 0028C)
+ * Section 7.4 SMCCC_ARCH_SOC_ID bits[23:16] are JEP-106 identification
+ * code with parity bit for the SiP. We can drop the parity bit.
+ */
+#define SMCCC_SOC_ID_JEP106_ID_CODE_MASK GENMASK(22, 16)
+#define SMCCC_SOC_ID_IMP_DEF_SOC_ID_MASK GENMASK(15, 0)
+
+#define JEP106_BANK_CONT_CODE(x) \
+ (u8)(FIELD_GET(SMCCC_SOC_ID_JEP106_BANK_IDX_MASK, (x)))
+#define JEP106_ID_CODE(x) \
+ (u8)(FIELD_GET(SMCCC_SOC_ID_JEP106_ID_CODE_MASK, (x)))
+#define IMP_DEF_SOC_ID(x) \
+ (u16)(FIELD_GET(SMCCC_SOC_ID_IMP_DEF_SOC_ID_MASK, (x)))
+
+static struct soc_device *soc_dev;
+static struct soc_device_attribute *soc_dev_attr;
+
+static int __init smccc_soc_init(void)
+{
+ struct arm_smccc_res res;
+ int soc_id_rev, soc_id_version;
+ static char soc_id_str[8], soc_id_rev_str[12];
+ static char soc_id_jep106_id_str[8];
+
+ if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2)
+ return 0;
+
+ if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE) {
+ pr_err("%s: invalid SMCCC conduit\n", __func__);
+ return -EOPNOTSUPP;
+ }
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ ARM_SMCCC_ARCH_SOC_ID, &res);
+
+ if (res.a0 == SMCCC_RET_NOT_SUPPORTED) {
+ pr_info("ARCH_SOC_ID not implemented, skipping ....\n");
+ return 0;
+ }
+
+ if ((int)res.a0 < 0) {
+ pr_info("ARCH_FEATURES(ARCH_SOC_ID) returned error: %lx\n",
+ res.a0);
+ return -EINVAL;
+ }
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 0, &res);
+ if ((int)res.a0 < 0) {
+ pr_err("ARCH_SOC_ID(0) returned error: %lx\n", res.a0);
+ return -EINVAL;
+ }
+
+ soc_id_version = res.a0;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 1, &res);
+ if ((int)res.a0 < 0) {
+ pr_err("ARCH_SOC_ID(1) returned error: %lx\n", res.a0);
+ return -EINVAL;
+ }
+
+ soc_id_rev = res.a0;
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ sprintf(soc_id_str, "0x%04x", IMP_DEF_SOC_ID(soc_id_version));
+ sprintf(soc_id_rev_str, "0x%08x", soc_id_rev);
+ sprintf(soc_id_jep106_id_str, "0x%02x%02x",
+ JEP106_BANK_CONT_CODE(soc_id_version),
+ JEP106_ID_CODE(soc_id_version));
+
+ soc_dev_attr->soc_id = soc_id_str;
+ soc_dev_attr->revision = soc_id_rev_str;
+ soc_dev_attr->jep106_id = soc_id_jep106_id_str;
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr);
+ return PTR_ERR(soc_dev);
+ }
+
+ pr_info("ID = %s Revision = %s\n", soc_dev_attr->soc_id,
+ soc_dev_attr->revision);
+
+ return 0;
+}
+module_init(smccc_soc_init);
+
+static void __exit smccc_soc_exit(void)
+{
+ if (soc_dev)
+ soc_device_unregister(soc_dev);
+ kfree(soc_dev_attr);
+}
+module_exit(smccc_soc_exit);
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 56d6a5c6e353..8254e11ea857 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -71,6 +71,11 @@
ARM_SMCCC_SMC_32, \
0, 1)
+#define ARM_SMCCC_ARCH_SOC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ 0, 2)
+
#define ARM_SMCCC_ARCH_WORKAROUND_1 \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
ARM_SMCCC_SMC_32, \
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] base: soc: Add JEP106 manufacturer's identification code
From: Sudeep Holla @ 2020-05-22 12:49 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Lorenzo Pieralisi, Arnd Bergmann,
Greg Kroah-Hartman, linux-kernel, harb, Sudeep Holla, Will Deacon
Hi,
While attempting to add custom sysfs attributes for SMCCC ARCH_SOC_ID
Arnd suggested to make it generic. Here is my first attempt.
The original thread/discussion can be found here[1]
Regards,
Sudeep
[1] https://lore.kernel.org/r/CAK8P3a3dV0B26XE3oFQGTFf8EWV0AHoLudNtpSSB_t+pCfkOkQ@mail.gmail.com/
Sudeep Holla (2):
base: soc: Add JEDEC JEP106 manufacturer's identification code attribute
firmware: smccc: Add ARCH_SOC_ID support
Documentation/ABI/testing/sysfs-devices-soc | 31 ++++++
drivers/base/soc.c | 12 +++
drivers/firmware/smccc/Kconfig | 9 ++
drivers/firmware/smccc/Makefile | 1 +
drivers/firmware/smccc/soc_id.c | 113 ++++++++++++++++++++
include/linux/arm-smccc.h | 5 +
include/linux/sys_soc.h | 1 +
7 files changed, 172 insertions(+)
create mode 100644 drivers/firmware/smccc/soc_id.c
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:qcom/dt] BUILD SUCCESS 7d2f29e49477aa51339e719cf73f0945c39c8a9e
From: kbuild test robot @ 2020-05-22 12:41 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/dt
branch HEAD: 7d2f29e49477aa51339e719cf73f0945c39c8a9e arm64: dts: qcom: sc7180: Correct the pdc interrupt ranges
elapsed time: 886m
configs tested: 110
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa defconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
arc defconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
arc allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allnoconfig
s390 allmodconfig
s390 allyesconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allyesconfig
um allmodconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] mt76: mt7915: Fix build error
From: Kalle Valo @ 2020-05-22 12:40 UTC (permalink / raw)
To: YueHaibing
Cc: ryder.lee, YueHaibing, linux-wireless, yf.luo, chih-min.chen,
linux-kernel, matthias.bgg, yiwei.chung, linux-mediatek, netdev,
lorenzo.bianconi83, kuba, shayne.chen, davem, linux-arm-kernel,
nbd
In-Reply-To: <20200522034533.61716-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> In file included from ./include/linux/firmware.h:6:0,
> from drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:4:
> In function ‘__mt7915_mcu_msg_send’,
> inlined from ‘mt7915_mcu_send_message’ at drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:370:6:
> ./include/linux/compiler.h:396:38: error: call to ‘__compiletime_assert_545’ declared with attribute error: BUILD_BUG_ON failed: cmd == MCU_EXT_CMD_EFUSE_ACCESS && mcu_txd->set_query != MCU_Q_QUERY
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^
> ./include/linux/compiler.h:377:4: note: in definition of macro ‘__compiletime_assert’
> prefix ## suffix(); \
> ^~~~~~
> ./include/linux/compiler.h:396:2: note: in expansion of macro ‘_compiletime_assert’
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^~~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
> BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> ^~~~~~~~~~~~~~~~
> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:280:2: note: in expansion of macro ‘BUILD_BUG_ON’
> BUILD_BUG_ON(cmd == MCU_EXT_CMD_EFUSE_ACCESS &&
> ^~~~~~~~~~~~
>
> BUILD_BUG_ON is meaningless here, chang it to WARN_ON.
>
> Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
472f0a240250 mt76: mt7915: Fix build error
--
https://patchwork.kernel.org/patch/11564595/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v13 3/3] i2c: npcm7xx: Add support for slave mode for Nuvoton
From: Andy Shevchenko @ 2020-05-22 12:32 UTC (permalink / raw)
To: Tali Perry
Cc: devicetree, tmaimon77, yuenn, avifishman70, venture, openbmc, wsa,
brendanhiggins, ofery, linux-kernel, kfting, robh+dt, linux-i2c,
linux-arm-kernel, benjaminfair
In-Reply-To: <20200522113312.181413-4-tali.perry1@gmail.com>
On Fri, May 22, 2020 at 02:33:12PM +0300, Tali Perry wrote:
> Add support for slave mode for Nuvoton
> NPCM BMC I2C controller driver.
I guess it will require v14, so, few nits below.
...
> +const int npcm_i2caddr[I2C_NUM_OWN_ADDR] = {
> + NPCM_I2CADDR1, NPCM_I2CADDR2,
> + NPCM_I2CADDR3, NPCM_I2CADDR4,
> + NPCM_I2CADDR5, NPCM_I2CADDR6,
> + NPCM_I2CADDR7, NPCM_I2CADDR8,
> + NPCM_I2CADDR9, NPCM_I2CADDR10,
One TAB is enough.
> + };
No need to indent at all.
...
> + /* Set and enable the address */
> + iowrite8(sa_reg, bus->reg + npcm_i2caddr[(int)addr_type]);
I'm wondering why you need a casting here.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v13 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Andy Shevchenko @ 2020-05-22 12:27 UTC (permalink / raw)
To: Tali Perry
Cc: devicetree, tmaimon77, yuenn, avifishman70, venture, openbmc, wsa,
brendanhiggins, ofery, linux-kernel, kfting, robh+dt, linux-i2c,
linux-arm-kernel, benjaminfair
In-Reply-To: <20200522113312.181413-3-tali.perry1@gmail.com>
On Fri, May 22, 2020 at 02:33:11PM +0300, Tali Perry wrote:
> Add Nuvoton NPCM BMC I2C controller driver.
I thought we are waiting for Wolfram finishing his review...
In any case see couple of comments below.
...
> +#ifdef CONFIG_DEBUG_FS
Now, do we need the rest of DEBUG_FS guards?
> + if (status) {
> + if (bus->rec_fail_cnt == ULLONG_MAX) {
> + dev_dbg(bus->dev, "rec_fail_cnt reach max, reset to 0");
> + bus->rec_fail_cnt = 0;
It's redundant, since we will anyway roll over when incrementing.
https://stackoverflow.com/q/18195715/2511795
> + }
> + bus->rec_fail_cnt++;
> + } else {
> + if (bus->rec_succ_cnt == ULLONG_MAX) {
> + dev_dbg(bus->dev, "rec_succ_cnt reach max, reset to 0");
> + bus->rec_succ_cnt = 0;
Ditto.
> + }
> + bus->rec_succ_cnt++;
> + }
> +#endif
...
> +static int npcm_i2c_remove_bus(struct platform_device *pdev)
> +{
> + unsigned long lock_flags;
> + struct npcm_i2c *bus = platform_get_drvdata(pdev);
> +
> + spin_lock_irqsave(&bus->lock, lock_flags);
> + npcm_i2c_disable(bus);
> + spin_unlock_irqrestore(&bus->lock, lock_flags);
> + i2c_del_adapter(&bus->adap);
> + debugfs_remove_recursive(bus->debugfs);
This should be in reversed order, i.e. you inited last in ->probe(), thus
should remove first in ->remove().
> + return 0;
> +}
...
> +static int __init npcm_i2c_init(void)
> +{
> + struct dentry *dir;
> +
> + dir = debugfs_create_dir("i2c", NULL);
> + if (IS_ERR_OR_NULL(dir))
IS_ERR() is redundant. And NULL already being checked inside i2c_init_debugfs()
or how do you call it?
> + return 0;
> +
> + npcm_i2c_debugfs_dir = dir;
> + return 0;
> +}
> +
> +static void __exit npcm_i2c_exit(void)
> +{
> + debugfs_remove_recursive(npcm_i2c_debugfs_dir);
> +}
> +
> +module_init(npcm_i2c_init);
> +module_exit(npcm_i2c_exit);
Slightly better to attach to the respective function, like other macros above
do.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/3] scsi: ufs-mediatek: Fix imprecise waiting time for ref-clk control
From: Stanley Chu @ 2020-05-22 12:18 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200522121814.9100-1-stanley.chu@mediatek.com>
Currently ref-clk control timeout is implemented by Jiffies. However
jiffies is not accurate enough thus "false timeout" may happen.
Use more accurate delay mechanism instead, for example, ktime.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 7 ++++---
drivers/scsi/ufs/ufs-mediatek.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index d56ce8d97d4e..523ee5573921 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -120,7 +120,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
struct arm_smccc_res res;
- unsigned long timeout;
+ ktime_t timeout, time_checked;
u32 value;
if (host->ref_clk_enabled == on)
@@ -135,8 +135,9 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
}
/* Wait for ack */
- timeout = jiffies + msecs_to_jiffies(REFCLK_REQ_TIMEOUT_MS);
+ timeout = ktime_add_us(ktime_get(), REFCLK_REQ_TIMEOUT_US);
do {
+ time_checked = ktime_get();
value = ufshcd_readl(hba, REG_UFS_REFCLK_CTRL);
/* Wait until ack bit equals to req bit */
@@ -144,7 +145,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
goto out;
usleep_range(100, 200);
- } while (time_before(jiffies, timeout));
+ } while (ktime_before(time_checked, timeout));
dev_err(hba->dev, "missing ack of refclk req, reg: 0x%x\n", value);
diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
index 5bbd3e9cbae2..fc42dcbfd800 100644
--- a/drivers/scsi/ufs/ufs-mediatek.h
+++ b/drivers/scsi/ufs/ufs-mediatek.h
@@ -28,7 +28,7 @@
#define REFCLK_REQUEST BIT(0)
#define REFCLK_ACK BIT(1)
-#define REFCLK_REQ_TIMEOUT_MS 3
+#define REFCLK_REQ_TIMEOUT_US 3000
/*
* Vendor specific pre-defined parameters
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 3/3] scsi: ufs-mediatek: Introduce low-power mode for device power supply
From: Stanley Chu @ 2020-05-22 12:18 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200522121814.9100-1-stanley.chu@mediatek.com>
Allow device power supply to enter low-power mode if device will
do nothing to save more power.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Pengshun Zhao <pengshun.zhao@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 3c85f5e97dea..5f41b7b7db8f 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -12,6 +12,7 @@
#include <linux/of_address.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
#include <linux/soc/mediatek/mtk_sip_svc.h>
#include "ufshcd.h"
@@ -521,6 +522,19 @@ static int ufs_mtk_link_set_lpm(struct ufs_hba *hba)
return 0;
}
+static void ufs_mtk_vreg_set_lpm(struct ufs_hba *hba, bool lpm)
+{
+ if (!hba->vreg_info.vccq2)
+ return;
+
+ if (lpm & !hba->vreg_info.vcc->enabled)
+ regulator_set_mode(hba->vreg_info.vccq2->reg,
+ REGULATOR_MODE_IDLE);
+ else if (!lpm)
+ regulator_set_mode(hba->vreg_info.vccq2->reg,
+ REGULATOR_MODE_NORMAL);
+}
+
static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
{
int err;
@@ -537,6 +551,12 @@ static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
ufshcd_set_link_off(hba);
return -EAGAIN;
}
+ /*
+ * Make sure no error will be returned to prevent
+ * ufshcd_suspend() re-enabling regulators while vreg is still
+ * in low-power mode.
+ */
+ ufs_mtk_vreg_set_lpm(hba, true);
}
if (!ufshcd_is_link_active(hba))
@@ -554,6 +574,7 @@ static int ufs_mtk_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
phy_power_on(host->mphy);
if (ufshcd_is_link_hibern8(hba)) {
+ ufs_mtk_vreg_set_lpm(hba, false);
err = ufs_mtk_link_set_hpm(hba);
if (err) {
err = ufshcd_link_recovery(hba);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 0/3] scsi: ufs-mediatek: Fix clk-gating and introduce low-power mode for vccq2
From: Stanley Chu @ 2020-05-22 12:18 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
Hi,
This patchset fixes a clk-gating issue and introduces low-power mode for vccq2 in MediaTek platforms.
Stanley Chu (3):
scsi: ufs-mediatek: Fix imprecise waiting time for ref-clk control
scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is not entered
yet
scsi: ufs-mediatek: Introduce low-power mode for device power supply
drivers/scsi/ufs/ufs-mediatek.c | 64 ++++++++++++++++++++++++++-------
drivers/scsi/ufs/ufs-mediatek.h | 2 +-
2 files changed, 53 insertions(+), 13 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 2/3] scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is not entered yet
From: Stanley Chu @ 2020-05-22 12:18 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200522121814.9100-1-stanley.chu@mediatek.com>
There are some chances that link enters hibern8 lately by auto-hibern8
scheme during the clock-gating flow. Clocks shall not be gated if link
is still active otherwise host or device may hang.
Fix this by returning error code to the caller __ufshcd_setup_clocks()
to skip gating clocks there if link is not confirmed in hibern8
state yet.
Also allow some waiting time for the hibern8 state transition.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 36 ++++++++++++++++++++++++---------
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 523ee5573921..3c85f5e97dea 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -178,15 +178,30 @@ static void ufs_mtk_setup_ref_clk_wait_us(struct ufs_hba *hba,
host->ref_clk_ungating_wait_us = ungating_us;
}
-static u32 ufs_mtk_link_get_state(struct ufs_hba *hba)
+int ufs_mtk_wait_link_state(struct ufs_hba *hba, u32 state,
+ unsigned long max_wait_ms)
{
+ ktime_t timeout, time_checked;
u32 val;
- ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
- val = ufshcd_readl(hba, REG_UFS_PROBE);
- val = val >> 28;
+ timeout = ktime_add_us(ktime_get(), ms_to_ktime(max_wait_ms));
+ do {
+ time_checked = ktime_get();
+ ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
+ val = ufshcd_readl(hba, REG_UFS_PROBE);
+ val = val >> 28;
+
+ if (val == state)
+ return 0;
- return val;
+ /* Sleep for max. 200us */
+ usleep_range(100, 200);
+ } while (ktime_before(time_checked, timeout));
+
+ if (val == state)
+ return 0;
+
+ return -ETIMEDOUT;
}
/**
@@ -221,10 +236,13 @@ static int ufs_mtk_setup_clocks(struct ufs_hba *hba, bool on,
* triggered by Auto-Hibern8.
*/
if (!ufshcd_can_hibern8_during_gating(hba) &&
- ufshcd_is_auto_hibern8_enabled(hba) &&
- ufs_mtk_link_get_state(hba) ==
- VS_LINK_HIBERN8)
- ufs_mtk_setup_ref_clk(hba, on);
+ ufshcd_is_auto_hibern8_enabled(hba)) {
+ ret = ufs_mtk_wait_link_state(hba,
+ VS_LINK_HIBERN8,
+ 15);
+ if (!ret)
+ ufs_mtk_setup_ref_clk(hba, on);
+ }
}
} else if (on && status == POST_CHANGE) {
ret = phy_power_on(host->mphy);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [soc:hisi/defconfig] BUILD SUCCESS 528443e32a3d53000d30bb8be04a382b04e57470
From: kbuild test robot @ 2020-05-22 12:13 UTC (permalink / raw)
To: Wei Xu; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git hisi/defconfig
branch HEAD: 528443e32a3d53000d30bb8be04a382b04e57470 arm64: defconfig: Enable UACCE/PCI PASID/SEC2/HPRE configs
elapsed time: 10705m
configs tested: 335
configs skipped: 147
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
mips allyesconfig
m68k allyesconfig
sparc allyesconfig
sh sh03_defconfig
arm vf610m4_defconfig
h8300 defconfig
m68k hp300_defconfig
powerpc pq2fads_defconfig
parisc alldefconfig
sh sh7770_generic_defconfig
arm mvebu_v7_defconfig
arm u300_defconfig
arm u8500_defconfig
arm spitz_defconfig
microblaze defconfig
mips cavium_octeon_defconfig
powerpc64 alldefconfig
arm integrator_defconfig
arc nsimosci_hs_defconfig
arm at91_dt_defconfig
sh sdk7786_defconfig
powerpc gamecube_defconfig
ia64 bigsur_defconfig
sh sh7757lcr_defconfig
powerpc mpc5200_defconfig
arm clps711x_defconfig
mips xway_defconfig
mips maltaup_defconfig
arm hisi_defconfig
um defconfig
arm mmp2_defconfig
mips loongson1c_defconfig
arm ep93xx_defconfig
arc nsimosci_defconfig
um allnoconfig
sh secureedge5410_defconfig
sh apsh4ad0a_defconfig
powerpc allmodconfig
s390 debug_defconfig
sh ap325rxa_defconfig
c6x defconfig
h8300 h8300h-sim_defconfig
arc axs103_smp_defconfig
mips qi_lb60_defconfig
openrisc or1ksim_defconfig
sh lboxre2_defconfig
c6x evmc6457_defconfig
arm corgi_defconfig
mips cu1000-neo_defconfig
arm ixp4xx_defconfig
arm mps2_defconfig
arm davinci_all_defconfig
mips db1xxx_defconfig
arm64 alldefconfig
sh sh2007_defconfig
arm sama5_defconfig
arm realview_defconfig
arm spear13xx_defconfig
arm shannon_defconfig
riscv nommu_k210_defconfig
powerpc ppc64e_defconfig
parisc generic-32bit_defconfig
arc alldefconfig
sh sh7710voipgw_defconfig
arm pleb_defconfig
h8300 alldefconfig
microblaze mmu_defconfig
powerpc ppc44x_defconfig
c6x evmc6678_defconfig
parisc defconfig
mips tb0219_defconfig
s390 allyesconfig
arm omap1_defconfig
arm lubbock_defconfig
arm badge4_defconfig
sh se7705_defconfig
sh se7724_defconfig
powerpc g5_defconfig
arm tegra_defconfig
arc defconfig
arm shmobile_defconfig
m68k m5208evb_defconfig
sparc64 allmodconfig
mips lasat_defconfig
arm hackkit_defconfig
mips e55_defconfig
sh allnoconfig
arc vdk_hs38_defconfig
sh se7751_defconfig
arm netwinder_defconfig
arm iop32x_defconfig
mips ath25_defconfig
mips malta_defconfig
arm assabet_defconfig
arm exynos_defconfig
m68k defconfig
arm h3600_defconfig
ia64 allnoconfig
mips loongson3_defconfig
sparc64 allyesconfig
mips tb0287_defconfig
powerpc mgcoge_defconfig
um x86_64_defconfig
powerpc storcenter_defconfig
sh shmin_defconfig
arm zx_defconfig
i386 allnoconfig
powerpc ps3_defconfig
sparc64 defconfig
arm keystone_defconfig
m68k m5272c3_defconfig
parisc allyesconfig
mips decstation_defconfig
mips lemote2f_defconfig
arm axm55xx_defconfig
sh se7722_defconfig
sh rsk7203_defconfig
arm viper_defconfig
powerpc tqm8xx_defconfig
arm stm32_defconfig
powerpc holly_defconfig
mips tb0226_defconfig
arm lpc18xx_defconfig
arm cns3420vb_defconfig
riscv nommu_virt_defconfig
microblaze nommu_defconfig
sh r7780mp_defconfig
arm pcm027_defconfig
powerpc ppc64_defconfig
h8300 h8s-sim_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
sh se7712_defconfig
powerpc amigaone_defconfig
mips mtx1_defconfig
parisc generic-64bit_defconfig
c6x dsk6455_defconfig
parisc allnoconfig
mips maltaup_xpa_defconfig
m68k m5307c3_defconfig
mips nlm_xlr_defconfig
sh migor_defconfig
powerpc mpc512x_defconfig
nds32 defconfig
arm moxart_defconfig
um allyesconfig
mips rb532_defconfig
arm imote2_defconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc allyesconfig
sh allmodconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allnoconfig
x86_64 randconfig-a005-20200515
x86_64 randconfig-a003-20200515
x86_64 randconfig-a006-20200515
x86_64 randconfig-a004-20200515
x86_64 randconfig-a001-20200515
x86_64 randconfig-a002-20200515
x86_64 randconfig-a005-20200517
x86_64 randconfig-a003-20200517
x86_64 randconfig-a006-20200517
x86_64 randconfig-a004-20200517
x86_64 randconfig-a001-20200517
x86_64 randconfig-a002-20200517
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386 randconfig-a001-20200518
i386 randconfig-a003-20200518
i386 randconfig-a004-20200518
i386 randconfig-a002-20200518
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a006-20200515
i386 randconfig-a005-20200515
i386 randconfig-a003-20200515
i386 randconfig-a001-20200515
i386 randconfig-a004-20200515
i386 randconfig-a002-20200515
i386 randconfig-a006-20200517
i386 randconfig-a005-20200517
i386 randconfig-a003-20200517
i386 randconfig-a001-20200517
i386 randconfig-a004-20200517
i386 randconfig-a002-20200517
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a006-20200516
i386 randconfig-a005-20200516
i386 randconfig-a003-20200516
i386 randconfig-a001-20200516
i386 randconfig-a004-20200516
i386 randconfig-a002-20200516
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a016-20200518
x86_64 randconfig-a012-20200518
x86_64 randconfig-a015-20200518
x86_64 randconfig-a013-20200518
x86_64 randconfig-a011-20200518
x86_64 randconfig-a014-20200518
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
i386 randconfig-a012-20200517
i386 randconfig-a016-20200517
i386 randconfig-a014-20200517
i386 randconfig-a011-20200517
i386 randconfig-a013-20200517
i386 randconfig-a015-20200517
i386 randconfig-a012-20200518
i386 randconfig-a014-20200518
i386 randconfig-a016-20200518
i386 randconfig-a011-20200518
i386 randconfig-a015-20200518
i386 randconfig-a013-20200518
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
i386 randconfig-a012-20200515
i386 randconfig-a016-20200515
i386 randconfig-a014-20200515
i386 randconfig-a011-20200515
i386 randconfig-a013-20200515
i386 randconfig-a015-20200515
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a013-20200521
i386 randconfig-a012-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a016-20200521
i386 randconfig-a014-20200521
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 allnoconfig
um allmodconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:qcom/defconfig] BUILD SUCCESS 5ef3c35809ec74ab41a5cf93a5b6d60167661113
From: kbuild test robot @ 2020-05-22 12:13 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/defconfig
branch HEAD: 5ef3c35809ec74ab41a5cf93a5b6d60167661113 arm64: defconfig: enable Qualcomm IPA and RMNet modules
elapsed time: 484m
configs tested: 88
configs skipped: 100
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:arm/defconfig] BUILD SUCCESS fec6111ae32257bab9e218bfd8a30e135591717e
From: kbuild test robot @ 2020-05-22 12:14 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/defconfig
branch HEAD: fec6111ae32257bab9e218bfd8a30e135591717e Merge tag 'hisi-arm64-defconfig-for-5.8' of git://github.com/hisilicon/linux-hisi into arm/defconfig
elapsed time: 484m
configs tested: 88
configs skipped: 96
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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