| Message ID | 1484030515-16722-2-git-send-email-riteshh@codeaurora.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | Andy Gross |
| Headers | show |
On 2017/1/10 14:41, Ritesh Harjani wrote: > From: Sahitya Tummala <stummala@codeaurora.org> > > Add new host operation ->platform_dumpregs to provide a > mechanism through which host drivers can dump platform > specific registers in addition to SDHC registers > during error conditions. > Although we have been preventing from adding new callback for sdhci core, this one makes sense as there are more and more vendor registers outside the scope of SDHCI spec. > Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> > Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> > --- > drivers/mmc/host/sdhci.c | 3 +++ > drivers/mmc/host/sdhci.h | 1 + > 2 files changed, 4 insertions(+) > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index 2390980..73a8918 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -101,6 +101,9 @@ static void sdhci_dumpregs(struct sdhci_host *host) > readl(host->ioaddr + SDHCI_ADMA_ADDRESS)); > } > > + if (host->ops->platform_dumpregs) > + host->ops->platform_dumpregs(host); > + > pr_err(DRIVER_NAME ": ===========================================\n"); > } > > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h > index 0b66f21..400f3a1 100644 > --- a/drivers/mmc/host/sdhci.h > +++ b/drivers/mmc/host/sdhci.h > @@ -564,6 +564,7 @@ struct sdhci_ops { > struct mmc_card *card, > unsigned int max_dtr, int host_drv, > int card_drv, int *drv_type); > + void (*platform_dumpregs)(struct sdhci_host *host); > }; > > #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS >
Hi Shawn, On 1/10/2017 2:45 PM, Shawn Lin wrote: > On 2017/1/10 14:41, Ritesh Harjani wrote: >> From: Sahitya Tummala <stummala@codeaurora.org> >> >> Add new host operation ->platform_dumpregs to provide a >> mechanism through which host drivers can dump platform >> specific registers in addition to SDHC registers >> during error conditions. >> > > Although we have been preventing from adding new callback > for sdhci core, this one makes sense as there are more and more > vendor registers outside the scope of SDHCI spec. Sure thanks, shall I add your Reviewed-by on this patch 1/3. Would you be able to review other as well?
On 18/01/17 09:57, Ritesh Harjani wrote: > Hi Shawn, > > On 1/10/2017 2:45 PM, Shawn Lin wrote: >> On 2017/1/10 14:41, Ritesh Harjani wrote: >>> From: Sahitya Tummala <stummala@codeaurora.org> >>> >>> Add new host operation ->platform_dumpregs to provide a >>> mechanism through which host drivers can dump platform >>> specific registers in addition to SDHC registers >>> during error conditions. >>> >> >> Although we have been preventing from adding new callback >> for sdhci core, this one makes sense as there are more and more >> vendor registers outside the scope of SDHCI spec. We are not prevented from adding new callbacks, but they have to represent logical functions not quirks. This patch seems fine to me except the name "platform_dumpregs" because "platform" doesn't mean "platform" here. Just plain "dumpregs" is better. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 1/19/2017 4:13 PM, Adrian Hunter wrote: > On 18/01/17 09:57, Ritesh Harjani wrote: >> Hi Shawn, >> >> On 1/10/2017 2:45 PM, Shawn Lin wrote: >>> On 2017/1/10 14:41, Ritesh Harjani wrote: >>>> From: Sahitya Tummala <stummala@codeaurora.org> >>>> >>>> Add new host operation ->platform_dumpregs to provide a >>>> mechanism through which host drivers can dump platform >>>> specific registers in addition to SDHC registers >>>> during error conditions. >>>> >>> >>> Although we have been preventing from adding new callback >>> for sdhci core, this one makes sense as there are more and more >>> vendor registers outside the scope of SDHCI spec. > > We are not prevented from adding new callbacks, but they have to represent > logical functions not quirks. > > This patch seems fine to me except the name "platform_dumpregs" because I took platform prefix similar to platform_execute_tuning. > "platform" doesn't mean "platform" here. Just plain "dumpregs" is better. Sure, I will only keep "dumpregs" in next revision. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 2390980..73a8918 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -101,6 +101,9 @@ static void sdhci_dumpregs(struct sdhci_host *host) readl(host->ioaddr + SDHCI_ADMA_ADDRESS)); } + if (host->ops->platform_dumpregs) + host->ops->platform_dumpregs(host); + pr_err(DRIVER_NAME ": ===========================================\n"); } diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index 0b66f21..400f3a1 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -564,6 +564,7 @@ struct sdhci_ops { struct mmc_card *card, unsigned int max_dtr, int host_drv, int card_drv, int *drv_type); + void (*platform_dumpregs)(struct sdhci_host *host); }; #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS