[PATCH] cxl: Fix ambiguous else warnings
Every time I build cxl I see the following warnings:
/scratch/dja/linux-capi/drivers/misc/cxl/pci.c: In function ‘sanitise_afu_regs’:
/scratch/dja/linux-capi/drivers/misc/cxl/pci.c:712:6: warning: suggest explicit
braces to avoid ambiguous ‘else’ [-Wparentheses]
if (reg & CXL_PSL_DSISR_TRANS)
^
/scratch/dja/linux-capi/drivers/misc/cxl/irq.c: In function ‘fail_psl_irq’:
/scratch/dja/linux-capi/drivers/misc/cxl/irq.c:184:5: warning: suggest explicit
braces to avoid ambiguous ‘else’ [-Wparentheses]
if (irq_info->dsisr & CXL_PSL_DSISR_TRANS)
^
They're annoying. Fix them by inserting the braces.
Signed-off-by: Daniel Axtens
---
drivers/misc/cxl/irq.c | 5 +++--
drivers/misc/cxl/pci.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/cxl/irq.c b/drivers/misc/cxl/irq.c
index 121ec48f3ab4..c11e583a15a9 100644
--- a/drivers/misc/cxl/irq.c
+++ b/drivers/misc/cxl/irq.c
@@ -181,10 +181,11 @@ static irqreturn_t cxl_irq(int irq, void *data, struct
cxl_irq_info *irq_info)
static irqreturn_t fail_psl_irq(struct cxl_afu *afu, struct cxl_irq_info
*irq_info)
{
- if (irq_info->dsisr & CXL_PSL_DSISR_TRANS)
+ if (irq_info->dsisr & CXL_PSL_DSISR_TRANS) {
cxl_p2n_write(afu, CXL_PSL_TFC_An, CXL_PSL_TFC_An_AE);
- else
+ } else {
cxl_p2n_write(afu, CXL_PSL_TFC_An, CXL_PSL_TFC_An_A);
+ }
return IRQ_HANDLED;
}
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 6d2e538331b6..29c7e4eb309a 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -709,10 +709,11 @@ static int sanitise_afu_regs(struct cxl_afu *afu)
reg = cxl_p2n_read(afu, CXL_PSL_DSISR_An);
if (reg) {
dev_warn(&afu->dev, "AFU had pending DSISR: %#.16llx\n", reg);
- if (reg & CXL_PSL_DSISR_TRANS)
+ if (reg & CXL_PSL_DSISR_TRANS) {
cxl_p2n_write(afu, CXL_PSL_TFC_An, CXL_PSL_TFC_An_AE);
- else
+ } else {
cxl_p2n_write(afu, CXL_PSL_TFC_An, CXL_PSL_TFC_An_A);
+ }
}
reg = cxl_p1n_read(afu, CXL_PSL_SERR_An);
if (reg) {
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
On Thu, Jul 30, 2015 at 04:35:58PM +0200, Maciej S. Szmigiero wrote:
> Adjust set DAI format function in fsl_ssi driver so it
> doesn't fail and clears RXDIR in AC'97 mode.
>
> Signed-off-by: Maciej Szmigiero
> ---
> sound/soc/fsl/fsl_ssi.c |8 +---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 8e5ff5e..37aabe3 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -900,14 +900,16 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
> scr &= ~CCSR_SSI_SCR_SYS_CLK_EN;
> break;
> default:
> - return -EINVAL;
> + if (!fsl_ssi_is_ac97(ssi_private))
> + return -EINVAL;
I think it would be better to add another case for the other mode which
is supported (AC97) instead of using the default case.
> }
>
> stcr |= strcr;
> srcr |= strcr;
>
> - if (ssi_private->cpu_dai_drv.symmetric_rates) {
> - /* Need to clear RXDIR when using SYNC mode */
> + if (ssi_private->cpu_dai_drv.symmetric_rates
> + || fsl_ssi_is_ac97(ssi_private)) {
Please fix this indention. Most of the driver is written with 2 tab
indention after a line break and the new policy seems to be to indent on
the opening bracket.
Regards,
Markus
> + /* Need to clear RXDIR when using SYNC or AC97 mode */
> srcr &= ~CCSR_SSI_SRCR_RXDIR;
> scr |= CCSR_SSI_SCR_SYN;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
On Fri, Jul 31, 2015 at 07:27:19AM +0200, Markus Pargmann wrote:
> Hi,
>
> On Thu, Jul 30, 2015 at 04:34:19PM +0200, Maciej S. Szmigiero wrote:
> > AC'97 bus can support asymmetric playback/capture rates
> > so enable them in this case in fsl_ssi driver.
> >
> > Signed-off-by: Maciej Szmigiero
> > ---
> > sound/soc/fsl/fsl_ssi.c |4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> > index a83b900..7f4f0b9 100644
> > --- a/sound/soc/fsl/fsl_ssi.c
> > +++ b/sound/soc/fsl/fsl_ssi.c
> > @@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
> >
> > /* Are the RX and the TX clocks locked? */
> > if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
> > - ssi_private->cpu_dai_drv.symmetric_rates = 1;
> > + if (!fsl_ssi_is_ac97(ssi_private))
> > + ssi_private->cpu_dai_drv.symmetric_rates = 1;
> > +
>
> Why don't you use the DT property that is parsed here to enable
> asymmetric rates?
Just found the last version of this series. Please use v2 and describe
changes for a new iteration of a series.
There is also a different setup with AC97 which does not use DMA. See
the long comment at the top of the file about how ac97 is already used.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] ASoC: fsl_ssi: instantiate AC'97 CODEC
On Thu, Jul 30, 2015 at 04:35:23PM +0200, Maciej S. Szmigiero wrote:
> Instantiate AC'97 CODEC in fsl_ssi driver AC'97 mode.
>
> Signed-off-by: Maciej Szmigiero
> ---
> sound/soc/fsl/fsl_ssi.c | 21 +
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 154bcf6..8e5ff5e 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1460,6 +1460,27 @@ done:
> _fsl_ssi_set_dai_fmt(&pdev->dev, ssi_private,
>ssi_private->dai_fmt);
>
> + if (fsl_ssi_is_ac97(ssi_private)) {
> + u32 ssi_idx;
> +
> + ret = of_property_read_u32(np, "cell-index", &ssi_idx);
This property is not set anywhere in the imx* DTs.
> + if (ret) {
> + dev_err(&pdev->dev, "cannot get SSI index property\n");
> + goto error_sound_card;
> + }
> +
> + ssi_private->pdev =
> + platform_device_register_data(NULL,
> + "ac97-codec", ssi_idx, NULL, 0);
If you really want to create a device at this point you should use
PLATFORM_DEVID_AUTO. I would prefer something where this is created in
DT. On the other side it is a discoverable bus..
Regards,
Markus
> + if (IS_ERR(ssi_private->pdev)) {
> + ret = PTR_ERR(ssi_private->pdev);
> + dev_err(&pdev->dev,
> + "failed to register AC97 codec platform: %d\n",
> + ret);
> + goto error_sound_card;
> + }
> + }
> +
> return 0;
>
> error_sound_card:
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
Hi,
On Thu, Jul 30, 2015 at 04:34:19PM +0200, Maciej S. Szmigiero wrote:
> AC'97 bus can support asymmetric playback/capture rates
> so enable them in this case in fsl_ssi driver.
>
> Signed-off-by: Maciej Szmigiero
> ---
> sound/soc/fsl/fsl_ssi.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index a83b900..7f4f0b9 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
>
> /* Are the RX and the TX clocks locked? */
> if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
> - ssi_private->cpu_dai_drv.symmetric_rates = 1;
> + if (!fsl_ssi_is_ac97(ssi_private))
> + ssi_private->cpu_dai_drv.symmetric_rates = 1;
> +
Why don't you use the DT property that is parsed here to enable
asymmetric rates?
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/ftrace: add powerpc timebase as a trace clock source
On 2015/04/24 02:24PM, Naveen N Rao wrote: > Add a new powerpc-specific trace clock using the timebase register, > similar to x86-tsc. This gives us > - a fast, monotonic, hardware clock source for trace entries, and > - a clock that can be used to correlate events across cpus as well as across > hypervisor and guests. > > Signed-off-by: Naveen N. Rao > --- > Changes since v1: > - removed unnecessary #ifdef in trace_clock.h > - changed config build dependency for trace_clock.o from TRACE_CLOCK to > TRACING Bump. Michael, can you please pick this up? - Naveen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/eeh-powernv: Fix unbalanced IRQ warning
On Thu, 2015-30-07 at 06:53:54 UTC, Alistair Popple wrote: > pnv_eeh_next_error() re-enables the eeh opal event interrupt but it > gets called from a loop if there are more outstanding events to > process, resulting in a warning due to enabling an already enabled > interrupt. Instead the interrupt should only be re-enabled once the > last outstanding event has been processed. > > Tested-by: Daniel Axtens > Reported-by: Daniel Axtens > Signed-off-by: Alistair Popple > Acked-by: Gavin Shan Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/b8d65e9662b1ffb3b52a cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [kernel] powerpc/powernv/ioda2: Fix calculation for memory allocated for TCE table
On Mon, 2015-20-07 at 10:45:51 UTC, Alexey Kardashevskiy wrote: > The existing code stores the amount of memory allocated for a TCE table. > At the moment it uses @offset which is a virtual offset in the TCE table > which is only correct for a one level tables and it does not include > memory allocated for intermediate levels. When multilevel TCE table is > requested, WARN_ON in tce_iommu_create_table() prints a warning. > > This adds an additional counter to pnv_pci_ioda2_table_do_alloc_pages() > to count actually allocated memory. > > Signed-off-by: Alexey Kardashevskiy > Reviewed-by: David Gibson Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/3ba3a73e9f204ce7904c cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: macintosh/ans-lcd: fix build failure after module_init/exit relocation
On Fri, 2015-17-07 at 13:20:31 UTC, Luis Henriques wrote:
> After commit 0fd972a7d91d ("module: relocate module_init from init.h to
> module.h")
> ans-lcd module fails to build with:
>
> drivers/macintosh/ans-lcd.c:201:1: warning: data definition has no type or
> storage class [enabled by default]
> module_init(anslcd_init);
> ^
> drivers/macintosh/ans-lcd.c:201:1: error: type defaults to 'int' in
> declaration of 'module_init' [-Werror=implicit-int]
> drivers/macintosh/ans-lcd.c:201:1: warning: parameter names (without types)
> in function declaration [enabled by default]
> drivers/macintosh/ans-lcd.c:202:1: warning: data definition has no type or
> storage class [enabled by default]
> module_exit(anslcd_exit);
> ^
> drivers/macintosh/ans-lcd.c:202:1: error: type defaults to 'int' in
> declaration of 'module_exit' [-Werror=implicit-int]
> drivers/macintosh/ans-lcd.c:202:1: warning: parameter names (without types)
> in function declaration [enabled by default]
> drivers/macintosh/ans-lcd.c:155:1: warning: 'anslcd_init' defined but not
> used [-Wunused-function]
> anslcd_init(void)
> ^
> drivers/macintosh/ans-lcd.c:195:1: warning: 'anslcd_exit' defined but not
> used [-Wunused-function]
> anslcd_exit(void)
> ^
>
> This commit fixes it by replacing linux/init.h by linux/module.h.
>
> Fixes: 0fd972a7d91d ("module: relocate module_init from init.h to module.h")
> Signed-off-by: Luis Henriques
> Acked-by: Paul Gortmaker
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/120d200a86273d1840d0
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR
On Fri, Jul 31, 2015 at 10:13:26AM +1000, Gavin Shan wrote:
>On Thu, Jul 30, 2015 at 01:43:59PM +0800, Wei Yang wrote:
>>On Thu, Jul 30, 2015 at 11:15:01AM +1000, Gavin Shan wrote:
>>>On Wed, Jul 29, 2015 at 03:22:07PM +0800, Wei Yang wrote:
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BAR in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
This patch changes the design by using one M64 BAR in Single PE mode for
one VF BAR. This gives absolute isolation for VFs.
Signed-off-by: Wei Yang
---
arch/powerpc/include/asm/pci-bridge.h |5 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 104
+
2 files changed, 18 insertions(+), 91 deletions(-)
>>>
>>>questions regarding this:
>>>
>>>(1) When M64 BAR is running in single-PE-mode for VFs, the alignment for one
>>>particular IOV BAR still have to be (IOV_BAR_size * max_vf_number), or
>>>M64 segment size of last BAR (0x1000) is fine? If the later one is
>>> fine,
>>>more M64 space would be saved. On the other hand, if the IOV BAR size
>>>(for all VFs) is less than 256MB, will the allocated resource conflict
>>>with the M64 segments in last BAR?
>>
>>Not need to be IOV BAR size aligned, be individual VF BAR size aligned is
>>fine.
>>
>>IOV BAR size = VF BAR size * expended_num_vfs
>>
>
>The (15th) last PHB's M64 BAR is divided into 256 segments and the size for
>each of them is 256MB. Lets have an example: PF has one M64 BAR (128MB) and it
>supports 8 VFs. The VF BAR size is 128MB and the IOV BAR size is (128MB * 8).
>If we take the VF BAR size (128MB) as the alignment, the MMIO might be assigned
>to have following layout. PF and VF will be put into different PE#. So I think
>the correct alignment would be max{VF_bar_size, M64_segment_size}, or I missed
>something?
>
> +---++
> | PF's M64 BAR | VF BARs|
> +---++
> 0 128MB (128MB *9)
>
Ok, got your point. So the layout should be
++---+
| VF BARs| PF's M64 BAR |
++---+
0MB (128MB * 8)
>>>(2) When M64 BAR is in single-PE-mode, the PE numbers allocated for VFs need
>>>continuous or not.
>>
>>No, not need.
>>
>
>Ok. If you like, you can improve it to have discrete PE numbers when the PHB's
>M64 BARs for VFs runs in single-mode in separate patch.
>
Yep, good suggestion.
>>>(3) Each PF could have 6 IOV BARs and there're 15 available M64 BAR. It means
>>>only two VFs can be enabled in the extreme case. Would it be a problem?
>>>
>>
>>Yes, you are right.
>>
>>Based on Alexey's mail, full isolation is more important than more VFs.
>>
>
>Ok. Lets ignore this issue for now. Maybe it has to be considered in future.
>Here's another problem:
>
>(4) In pnv_pci_sriov_enable(), we can bail early when num_vfs >=
>phb_avaiable_M64_BARs.
>no need to allocate PE number and PHB's M64 BARs, then hit failure and
> release
>the allocated resources.
>
Yep, good suggestion.
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 712add5..1997e5d 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -214,10 +214,9 @@ struct pci_dn {
u16 vfs_expanded; /* number of VFs IOV BAR expanded */
u16 num_vfs;/* number of VFs enabled*/
int offset; /* PE# for the first VF PE */
-#define M64_PER_IOV 4
- int m64_per_iov;
+#define MAX_M64_WINDOW 16
#define IODA_INVALID_M64(-1)
- int m64_wins[PCI_SRIOV_NUM_BARS][M64_PER_IOV];
+ int m64_wins[PCI_SRIOV_NUM_BARS][MAX_M64_WINDOW];
#endif /* CONFIG_PCI_IOV */
#endif
>>>
>>>The "m64_wins" would be renamed to "m64_map". Also, it would have dynamic
>>>size:
>>>
>>>- When the IOV BAR is extended to 256 segments, its size is sizeof(int) *
>>>PCI_SRIOV_NUM_BARS;
>>>- When the IOV BAR is extended to max_vf_num, its size is sizeof(int) *
>>>max_vf_num;
>>>
struct list_head child_list;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 5738d31..b3e7909 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1168,7 +1168,7 @@ static int pnv_pci_vf_release_m64(struct pci_dev
*pdev)
pdn = pci_get_pdn(pdev);
for (i = 0; i < PCI_SRIOV_NUM_BARS; i++)
- for (j = 0; j < M64_PER_IOV; j++) {
+ for (j = 0; j < MAX_M64_WINDOW;
[PATCH 2/2] powerpc/85xx: Use kconfig fragments
Unify mpc85xx and corenet configs using fragments, to ease maintenance and avoid the sort of drift that the previous patch fixed. Hardware and software options are separated, with the hope that other embedded platforms could share the software options, and to make it easier to maintain custom/alternate configs that focus on either hardware or software options. Due to the previous patch, this patch should not affect the results of any of the affected defconfigs -- only how those results are achieved. The resulting config is more or less the union of the options that any of the configs previously selected. No attempt was made in this (or the previous) patch to edit out questionable options, but this patch will make it easier to do so in future patches. Signed-off-by: Scott Wood --- arch/powerpc/Makefile| 20 ++ arch/powerpc/configs/85xx-32bit.config | 5 + arch/powerpc/configs/85xx-64bit.config | 4 + arch/powerpc/configs/85xx-hw.config | 140 + arch/powerpc/configs/85xx-smp.config | 2 + arch/powerpc/configs/altivec.config | 1 + arch/powerpc/configs/corenet32_smp_defconfig | 264 arch/powerpc/configs/corenet64_smp_defconfig | 259 arch/powerpc/configs/corenet_basic_defconfig | 1 + arch/powerpc/configs/fsl-emb-nonhw.config| 126 arch/powerpc/configs/mpc85xx_basic_defconfig | 23 +++ arch/powerpc/configs/mpc85xx_defconfig | 288 -- arch/powerpc/configs/mpc85xx_smp_defconfig | 289 --- 13 files changed, 322 insertions(+), 1100 deletions(-) create mode 100644 arch/powerpc/configs/85xx-32bit.config create mode 100644 arch/powerpc/configs/85xx-64bit.config create mode 100644 arch/powerpc/configs/85xx-hw.config create mode 100644 arch/powerpc/configs/85xx-smp.config create mode 100644 arch/powerpc/configs/altivec.config delete mode 100644 arch/powerpc/configs/corenet32_smp_defconfig delete mode 100644 arch/powerpc/configs/corenet64_smp_defconfig create mode 100644 arch/powerpc/configs/corenet_basic_defconfig create mode 100644 arch/powerpc/configs/fsl-emb-nonhw.config create mode 100644 arch/powerpc/configs/mpc85xx_basic_defconfig delete mode 100644 arch/powerpc/configs/mpc85xx_defconfig delete mode 100644 arch/powerpc/configs/mpc85xx_smp_defconfig diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 05f464e..4ca54fd 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -288,6 +288,26 @@ PHONY += pseries_le_defconfig pseries_le_defconfig: $(call merge_into_defconfig,pseries_defconfig,le) +PHONY += mpc85xx_defconfig +mpc85xx_defconfig: + $(call merge_into_defconfig,mpc85xx_basic_defconfig,\ + 85xx-32bit 85xx-hw fsl-emb-nonhw) + +PHONY += mpc85xx_smp_defconfig +mpc85xx_smp_defconfig: + $(call merge_into_defconfig,mpc85xx_basic_defconfig,\ + 85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw) + +PHONY += corenet32_smp_defconfig +corenet32_smp_defconfig: + $(call merge_into_defconfig,corenet_basic_defconfig,\ + 85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw) + +PHONY += corenet64_smp_defconfig +corenet64_smp_defconfig: + $(call merge_into_defconfig,corenet_basic_defconfig,\ + 85xx-64bit 85xx-smp altivec 85xx-hw fsl-emb-nonhw) + define archhelp @echo '* zImage - Build default images selected by kernel config' @echo ' zImage.*- Compressed kernel image (arch/$(ARCH)/boot/zImage.*)' diff --git a/arch/powerpc/configs/85xx-32bit.config b/arch/powerpc/configs/85xx-32bit.config new file mode 100644 index 000..6b8894d --- /dev/null +++ b/arch/powerpc/configs/85xx-32bit.config @@ -0,0 +1,5 @@ +CONFIG_HIGHMEM=y +CONFIG_KEXEC=y +CONFIG_PPC_85xx=y +CONFIG_PROC_KCORE=y +CONFIG_PHYS_64BIT=y diff --git a/arch/powerpc/configs/85xx-64bit.config b/arch/powerpc/configs/85xx-64bit.config new file mode 100644 index 000..4aba812 --- /dev/null +++ b/arch/powerpc/configs/85xx-64bit.config @@ -0,0 +1,4 @@ +CONFIG_MATH_EMULATION=y +CONFIG_MATH_EMULATION_HW_UNIMPLEMENTED=y +CONFIG_PPC64=y +CONFIG_PPC_BOOK3E_64=y diff --git a/arch/powerpc/configs/85xx-hw.config b/arch/powerpc/configs/85xx-hw.config new file mode 100644 index 000..fa84e88 --- /dev/null +++ b/arch/powerpc/configs/85xx-hw.config @@ -0,0 +1,140 @@ +CONFIG_AT803X_PHY=y +CONFIG_ATA=y +CONFIG_BLK_DEV_SD=y +CONFIG_BLK_DEV_SR_VENDOR=y +CONFIG_BLK_DEV_SR=y +CONFIG_BROADCOM_PHY=y +CONFIG_C293_PCIE=y +CONFIG_CHR_DEV_SG=y +CONFIG_CHR_DEV_ST=y +CONFIG_CICADA_PHY=y +CONFIG_CLK_QORIQ=y +CONFIG_CRYPTO_DEV_FSL_CAAM=y +CONFIG_CRYPTO_DEV_TALITOS=y +CONFIG_DAVICOM_PHY=y +CONFIG_DMADEVICES=y +CONFIG_E1000E=y +CONFIG_E1000=y +CONFIG_EDAC_MM_EDAC=y +CONFIG_EDAC_MPC85XX=y +CONFIG_EDAC=y +CONFIG_EEPROM_AT24=y +CONFIG_EEPROM_LEGACY=y +CONFIG_FB_FSL_DIU=y +CONFIG_FS_ENET=y +CONFIG_FSL_CORENET_CF=y +CONFIG_FSL_DMA=y +CONFIG_FSL_HV_MANAGER=y +C
[PATCH 1/2] powerpc/85xx: Make defconfigs consistent
The mpc85xx and corenet configs have many differences between them that can't be explained by the target hardware of each config. The next patch will consolidate these targets using kconfig fragments; this patch shows what the resulting defconfigs will look like (generated by using savedefconfig on a fragment-generated config). Signed-off-by: Scott Wood --- arch/powerpc/configs/corenet32_smp_defconfig | 97 arch/powerpc/configs/corenet64_smp_defconfig | 97 +--- arch/powerpc/configs/mpc85xx_defconfig | 40 +++- arch/powerpc/configs/mpc85xx_smp_defconfig | 59 +++-- 4 files changed, 262 insertions(+), 31 deletions(-) diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index e47c1ff..c05f8b7 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -1,10 +1,11 @@ CONFIG_PPC_85xx=y CONFIG_SMP=y -CONFIG_NR_CPUS=8 +CONFIG_NR_CPUS=24 CONFIG_SYSVIPC=y -CONFIG_FHANDLE=y CONFIG_POSIX_MQUEUE=y +CONFIG_FHANDLE=y CONFIG_AUDIT=y +CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BSD_PROCESS_ACCT=y @@ -16,10 +17,9 @@ CONFIG_CPUSETS=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_SCHED=y CONFIG_BLK_DEV_INITRD=y +CONFIG_EXPERT=y CONFIG_KALLSYMS_ALL=y -CONFIG_EMBEDDED=y CONFIG_PERF_EVENTS=y -CONFIG_SLAB=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y @@ -27,7 +27,10 @@ CONFIG_MODVERSIONS=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y CONFIG_MAC_PARTITION=y +CONFIG_C293_PCIE=y CONFIG_CORENET_GENERIC=y +CONFIG_QUICC_ENGINE=y +CONFIG_QE_GPIO=y CONFIG_HIGHMEM=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_BINFMT_MISC=m @@ -64,6 +67,7 @@ CONFIG_IP_PIMSM_V2=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y +# CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set CONFIG_IPV6=y CONFIG_IP_SCTP=m @@ -73,20 +77,29 @@ CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y +CONFIG_FTL=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_PHYSMAP=y CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PLATRAM=y +CONFIG_MTD_M25P80=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_FSL_ELBC=y CONFIG_MTD_NAND_FSL_IFC=y CONFIG_MTD_SPI_NOR=y +CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=131072 +CONFIG_EEPROM_AT24=y +CONFIG_EEPROM_LEGACY=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y +CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SYM53C8XX_2=y @@ -95,17 +108,27 @@ CONFIG_SATA_AHCI=y CONFIG_SATA_FSL=y CONFIG_SATA_SIL24=y CONFIG_SATA_SIL=y +CONFIG_PATA_ALI=y CONFIG_PATA_SIL680=y +CONFIG_PATA_VIA=y CONFIG_NETDEVICES=y -CONFIG_FSL_PQ_MDIO=y +CONFIG_DUMMY=y CONFIG_FSL_XGMAC_MDIO=y +CONFIG_UCC_GETH=y +CONFIG_GIANFAR=y CONFIG_E1000=y CONFIG_E1000E=y +CONFIG_IGB=y CONFIG_AT803X_PHY=y +CONFIG_MARVELL_PHY=y +CONFIG_DAVICOM_PHY=y +CONFIG_CICADA_PHY=y CONFIG_VITESSE_PHY=y +CONFIG_BROADCOM_PHY=y CONFIG_FIXED_PHY=y CONFIG_MDIO_BUS_MUX_GPIO=y CONFIG_MDIO_BUS_MUX_MMIOREG=y +CONFIG_INPUT_FF_MEMLESS=m # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set @@ -114,21 +137,51 @@ CONFIG_SERIO_LIBPS2=y CONFIG_PPC_EPAPR_HV_BYTECHAN=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=6 +CONFIG_SERIAL_8250_RUNTIME_UARTS=6 CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y +CONFIG_SERIAL_QE=m CONFIG_NVRAM=y -CONFIG_I2C=y CONFIG_I2C_CHARDEV=y -CONFIG_I2C_MPC=y CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PCA954x=y +CONFIG_I2C_MPC=y CONFIG_SPI=y CONFIG_SPI_GPIO=y CONFIG_SPI_FSL_SPI=y CONFIG_SPI_FSL_ESPI=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_INA2XX=y +CONFIG_FB=y +CONFIG_FB_FSL_DIU=y +# CONFIG_VGA_CONSOLE is not set +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_SOUND=y +CONFIG_SND=y +# CONFIG_SND_SUPPORT_OLD_API is not set +# CONFIG_SND_DRIVERS is not set +CONFIG_SND_INTEL8X0=y +# CONFIG_SND_PPC is not set +# CONFIG_SND_USB is not set +CONFIG_SND_SOC=y +CONFIG_SND_POWERPC_SOC=y +CONFIG_HID_A4TECH=y +CONFIG_HID_APPLE=y +CONFIG_HID_BELKIN=y +CONFIG_HID_CHERRY=y +CONFIG_HID_CHICONY=y +CONFIG_HID_CYPRESS=y +CONFIG_HID_EZKEY=y +CONFIG_HID_GYRATION=y +CONFIG_HID_LOGITECH=y +CONFIG_HID_MICROSOFT=y +CONFIG_HID_MONTEREY=y +CONFIG_HID_PANTHERLORD=y +CONFIG_HID_PETALYNX=y +CONFIG_HID_SAMSUNG=y +CONFIG_HID_SUNPLUS=y CONFIG_USB_HID=m CONFIG_USB=y CONFIG_USB_MON=y @@ -149,14 +202,14 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_DS1374=y CONFIG_RTC_DRV_DS3232=y -CONFIG_UIO=y +CONFIG_RTC_DRV_CMOS=y CONFIG_DMADEVICES=y CONFIG_FSL_DMA=y +CONFIG_UIO=y CONFIG_VIRT_DRIVERS=y CONFIG_FSL_HV_MANAGER=y -CONFIG_STAGING=y -CONFIG_FSL_CORENET_CF=y CONFIG_CLK_QORIQ=y +CONFIG_FSL_CORENET_CF=y CONF
[PATCH 0/2] powerpc/85xx: Kconfig fragments
These patches sit on top of the following patches: http://patchwork.ozlabs.org/patch/499211/ http://patchwork.ozlabs.org/patch/499200/ http://patchwork.ozlabs.org/patch/468592/ Scott Wood (2): powerpc/85xx: Make defconfigs consistent powerpc/85xx: Use kconfig fragments arch/powerpc/Makefile| 20 +++ arch/powerpc/configs/85xx-32bit.config | 5 + arch/powerpc/configs/85xx-64bit.config | 4 + arch/powerpc/configs/85xx-hw.config | 140 +++ arch/powerpc/configs/85xx-smp.config | 2 + arch/powerpc/configs/altivec.config | 1 + arch/powerpc/configs/corenet32_smp_defconfig | 195 - arch/powerpc/configs/corenet64_smp_defconfig | 178 --- arch/powerpc/configs/corenet_basic_defconfig | 1 + arch/powerpc/configs/fsl-emb-nonhw.config| 126 ++ arch/powerpc/configs/mpc85xx_basic_defconfig | 23 +++ arch/powerpc/configs/mpc85xx_defconfig | 252 --- arch/powerpc/configs/mpc85xx_smp_defconfig | 244 -- 13 files changed, 322 insertions(+), 869 deletions(-) create mode 100644 arch/powerpc/configs/85xx-32bit.config create mode 100644 arch/powerpc/configs/85xx-64bit.config create mode 100644 arch/powerpc/configs/85xx-hw.config create mode 100644 arch/powerpc/configs/85xx-smp.config create mode 100644 arch/powerpc/configs/altivec.config delete mode 100644 arch/powerpc/configs/corenet32_smp_defconfig delete mode 100644 arch/powerpc/configs/corenet64_smp_defconfig create mode 100644 arch/powerpc/configs/corenet_basic_defconfig create mode 100644 arch/powerpc/configs/fsl-emb-nonhw.config create mode 100644 arch/powerpc/configs/mpc85xx_basic_defconfig delete mode 100644 arch/powerpc/configs/mpc85xx_defconfig delete mode 100644 arch/powerpc/configs/mpc85xx_smp_defconfig -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR
On Thu, Jul 30, 2015 at 01:43:59PM +0800, Wei Yang wrote:
>On Thu, Jul 30, 2015 at 11:15:01AM +1000, Gavin Shan wrote:
>>On Wed, Jul 29, 2015 at 03:22:07PM +0800, Wei Yang wrote:
>>>In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
>>>BAR in Single PE mode to cover the number of VFs required to be enabled.
>>>By doing so, several VFs would be in one VF Group and leads to interference
>>>between VFs in the same group.
>>>
>>>This patch changes the design by using one M64 BAR in Single PE mode for
>>>one VF BAR. This gives absolute isolation for VFs.
>>>
>>>Signed-off-by: Wei Yang
>>>---
>>> arch/powerpc/include/asm/pci-bridge.h |5 +-
>>> arch/powerpc/platforms/powernv/pci-ioda.c | 104
>>> +
>>> 2 files changed, 18 insertions(+), 91 deletions(-)
>>>
>>
>>questions regarding this:
>>
>>(1) When M64 BAR is running in single-PE-mode for VFs, the alignment for one
>>particular IOV BAR still have to be (IOV_BAR_size * max_vf_number), or
>>M64 segment size of last BAR (0x1000) is fine? If the later one is
>> fine,
>>more M64 space would be saved. On the other hand, if the IOV BAR size
>>(for all VFs) is less than 256MB, will the allocated resource conflict
>>with the M64 segments in last BAR?
>
>Not need to be IOV BAR size aligned, be individual VF BAR size aligned is fine.
>
>IOV BAR size = VF BAR size * expended_num_vfs
>
The (15th) last PHB's M64 BAR is divided into 256 segments and the size for
each of them is 256MB. Lets have an example: PF has one M64 BAR (128MB) and it
supports 8 VFs. The VF BAR size is 128MB and the IOV BAR size is (128MB * 8).
If we take the VF BAR size (128MB) as the alignment, the MMIO might be assigned
to have following layout. PF and VF will be put into different PE#. So I think
the correct alignment would be max{VF_bar_size, M64_segment_size}, or I missed
something?
+---++
| PF's M64 BAR | VF BARs|
+---++
0 128MB (128MB *9)
>>(2) When M64 BAR is in single-PE-mode, the PE numbers allocated for VFs need
>>continuous or not.
>
>No, not need.
>
Ok. If you like, you can improve it to have discrete PE numbers when the PHB's
M64 BARs for VFs runs in single-mode in separate patch.
>>(3) Each PF could have 6 IOV BARs and there're 15 available M64 BAR. It means
>>only two VFs can be enabled in the extreme case. Would it be a problem?
>>
>
>Yes, you are right.
>
>Based on Alexey's mail, full isolation is more important than more VFs.
>
Ok. Lets ignore this issue for now. Maybe it has to be considered in future.
Here's another problem:
(4) In pnv_pci_sriov_enable(), we can bail early when num_vfs >=
phb_avaiable_M64_BARs.
no need to allocate PE number and PHB's M64 BARs, then hit failure and
release
the allocated resources.
>>>diff --git a/arch/powerpc/include/asm/pci-bridge.h
>>>b/arch/powerpc/include/asm/pci-bridge.h
>>>index 712add5..1997e5d 100644
>>>--- a/arch/powerpc/include/asm/pci-bridge.h
>>>+++ b/arch/powerpc/include/asm/pci-bridge.h
>>>@@ -214,10 +214,9 @@ struct pci_dn {
>>> u16 vfs_expanded; /* number of VFs IOV BAR expanded */
>>> u16 num_vfs;/* number of VFs enabled*/
>>> int offset; /* PE# for the first VF PE */
>>>-#define M64_PER_IOV 4
>>>-int m64_per_iov;
>>>+#define MAX_M64_WINDOW 16
>>> #define IODA_INVALID_M64(-1)
>>>-int m64_wins[PCI_SRIOV_NUM_BARS][M64_PER_IOV];
>>>+int m64_wins[PCI_SRIOV_NUM_BARS][MAX_M64_WINDOW];
>>> #endif /* CONFIG_PCI_IOV */
>>> #endif
>>
>>The "m64_wins" would be renamed to "m64_map". Also, it would have dynamic
>>size:
>>
>>- When the IOV BAR is extended to 256 segments, its size is sizeof(int) *
>>PCI_SRIOV_NUM_BARS;
>>- When the IOV BAR is extended to max_vf_num, its size is sizeof(int) *
>>max_vf_num;
>>
>>> struct list_head child_list;
>>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>>>b/arch/powerpc/platforms/powernv/pci-ioda.c
>>>index 5738d31..b3e7909 100644
>>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>>@@ -1168,7 +1168,7 @@ static int pnv_pci_vf_release_m64(struct pci_dev *pdev)
>>> pdn = pci_get_pdn(pdev);
>>>
>>> for (i = 0; i < PCI_SRIOV_NUM_BARS; i++)
>>>-for (j = 0; j < M64_PER_IOV; j++) {
>>>+for (j = 0; j < MAX_M64_WINDOW; j++) {
>>> if (pdn->m64_wins[i][j] == IODA_INVALID_M64)
>>> continue;
>>> opal_pci_phb_mmio_enable(phb->opal_id,
>>>@@ -1193,8 +1193,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev,
>>>u16 num_vfs)
>>> inttotal_vfs;
>>> resource_size_tsize, start;
>>> intpe_num;
>>>-intvf_groups;
>>>-int
Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers
Hello Dmitry, Thanks a lot for your feedback. On 07/30/2015 06:37 PM, Dmitry Torokhov wrote: > On Thu, Jul 30, 2015 at 09:35:17AM -0700, Dmitry Torokhov wrote: >> Hi Javier, >> >> On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: >>> Hello, >>> >>> Short version: >>> >>> This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables >>> to export that information so modules have the correct aliases built-in >>> and autoloading works correctly. >>> >>> Longer version: >>> >>> Currently it's mandatory for I2C drivers to have an I2C device ID table >>> regardless if the device was registered using platform data or OF. This >>> is because the I2C core needs an I2C device ID table for two reasons: >>> >>> 1) Match the I2C client with a I2C device ID so a struct i2c_device_id >>>is passed to the I2C driver probe() function. >>> >>> 2) Export the module aliases from the I2C device ID table so userspace >>>can auto-load the correct module. This is because i2c_device_uevent >>>always reports a MODALIAS of the form i2c:name>. >> >> Why are we not fixing this? We emit specially carved uevent for >> ACPI-based devices, why not the same for OF? Platform bus does this... > > Ah, now I see the 27/27 patch. I think it is exactly what we need. And Yes, patch 27/27 is needed but the problem is as I explained before that there are drivers relying on the current behavior. The item c) in the list of issues that I mentioned. So those drivers need to be fixed before that patch is merged... > probably for SPI bus as well. > Yes, I didn't mention SPI because the cover letter became too long already but it does indeed have the same issue and I discussed this with Mark already some time ago [0]. Once I2C uevent report is fixed, I plan to do the same for SPI. > Thanks. > [0]: https://lkml.org/lkml/2014/9/11/458 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 27/27] i2c: (RFC, don't apply) report OF style modalias when probing using DT
An I2C driver that supports both OF and legacy platforms, will have both a OF and I2C ID table. This means that when built as a module, the aliases will be filled from both tables but currently always an alias of the form i2c: is reported, e.g: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias i2c:maxtouch So if a device is probed by matching its compatible string, udev can get a MODALIAS uevent env var that doesn't match with one of the valid aliases so the module won't be auto-loaded. This patch changes the I2C core to report a OF related MODALIAS uevent (of:N*T*C) env var instead so the module can be auto-loaded and also report the correct alias using sysfs: $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias of:NtrackpadTCatmel,maxtouch Signed-off-by: Javier Martinez Canillas --- drivers/i2c/i2c-core.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 92dddfeb3f39..c0668c2ed9da 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -489,6 +489,10 @@ static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env) struct i2c_client *client = to_i2c_client(dev); int rc; + rc = of_device_uevent_modalias(dev, env); + if (rc != -ENODEV) + return rc; + rc = acpi_device_uevent_modalias(dev, env); if (rc != -ENODEV) return rc; @@ -726,6 +730,10 @@ show_modalias(struct device *dev, struct device_attribute *attr, char *buf) struct i2c_client *client = to_i2c_client(dev); int len; + len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1); + if (len != -ENODEV) + return len; + len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); if (len != -ENODEV) return len; -- 2.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 22/27] macintosh: therm_windtunnel: Export OF module alias information
The I2C core always reports the MODALIAS uevent as "i2c:
---
drivers/macintosh/therm_windtunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
index 97269567ec01..68dcbcb4fc5b 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -460,6 +460,7 @@ static const struct of_device_id therm_of_match[] = {{
.compatible = "adm1030"
}, {}
};
+MODULE_DEVICE_TABLE(of, therm_of_match);
static struct platform_driver therm_of_driver = {
.driver = {
--
2.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/27] macintosh: therm_windtunnel: Export I2C module alias information
The I2C core always reports the MODALIAS uevent as "i2c:
---
drivers/macintosh/therm_windtunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
index 109dcaa15934..97269567ec01 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -408,6 +408,7 @@ static const struct i2c_device_id therm_windtunnel_id[] = {
{ "therm_adm1030", adm1030 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, therm_windtunnel_id);
static int
do_probe(struct i2c_client *cl, const struct i2c_device_id *id)
--
2.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/27] Export I2C and OF module aliases in missing drivers
Hello, Short version: This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables to export that information so modules have the correct aliases built-in and autoloading works correctly. Longer version: Currently it's mandatory for I2C drivers to have an I2C device ID table regardless if the device was registered using platform data or OF. This is because the I2C core needs an I2C device ID table for two reasons: 1) Match the I2C client with a I2C device ID so a struct i2c_device_id is passed to the I2C driver probe() function. 2) Export the module aliases from the I2C device ID table so userspace can auto-load the correct module. This is because i2c_device_uevent always reports a MODALIAS of the form i2c:name>. Lee Jones posted a patch series [0] to solve 1) by allowing the I2C drivers to have a probe() function that does not get a i2c_device_id. The problem is that his series didn't take into account 2) so if that was merged and the I2C ID table is removed from all the drivers that don't needed it, module auto-loading will break for those. But even now there are many I2C drivers were module auto-loading is not working because of the fact that the I2C core always reports the MODALIAS as i2c:name> and many developers didn't expect this. I've identified I2C drivers with 3 types of different issues: a) Those that have an i2c_table but are not exported. The match works and the correct i2c_device_id is passed on probe but since the ID table is not exported, module auto-load won't work. b) Those that have a of_table but are not exported. This is currently not an issue since even when the of_table is used to match the dev with the driver, an OF modalias is not reported by the I2C core. But if the I2C core is changed to report the MODALIAS of the form of:N*T*C as it's made by other subsystems, then module auto-load will break for these drivers. c) Those that don't have a of_table but should since are OF drivers with DT bindings doc for them. Since the I2C core does not report a OF modalias and since i2c_device_match() fallbacks to match the device part of the compatible string with the I2C device ID table, many OF drivers don't have an of_table to match. After all having a I2C device ID table is mandatory so it works without a of_table. So, in order to not make mandatory to have a I2C device ID table, at least a) and b) needs to be addressed, this series does that. c) should be fixed too since it seems wrong that a driver with a DT binding document, does not have a OF table and export it to modules. Also stripping the vendor part from the compatible string to match with the I2C devices ID table and reporting only the device name to user-space doesn't seem to be correct. I've identified at least two drivers that have the same name on their I2C device ID table so the manufacturer prefix is important. But I've not tried to fix c) yet since that is not so easy to automate due drivers not having all the information (i.e: the device name can match a documented compatible string device part but without the vendor prefix is hard to tell). I split the changes so the patches in this series are independent and can be picked individually by subsystem maintainers. Patch #27 changes the logic of i2c_device_uevent() to report an OF modalias if the device was registered using OF. But this patch is included in the series only as an RFC for illustration purposes since changing that without fixing c) will break module auto-loading for the drivers of devices registered with OF but that don't have a of_match_table. Although arguably, those drivers were relying on the assumption that a MODALIAS=i2c: would always be reported even for the OF case which is not the true on other subsystems. [0]: https://lkml.org/lkml/2014/8/28/283 Best regards, Javier Javier Martinez Canillas (27): mfd: stw481x: Export I2C module alias information spi: xcomm: Export I2C module alias information iio: Export I2C module alias information in missing drivers [media] Export I2C module alias information in missing drivers macintosh: therm_windtunnel: Export I2C module alias information misc: eeprom: Export I2C module alias information in missing drivers Input: Export I2C module alias information in missing drivers power: Export I2C module alias information in missing drivers i2c: core: Export I2C module alias information in dummy driver backlight: tosa: Export I2C module alias information [media] staging: media: lirc: Export I2C module alias information usb: phy: isp1301: Export I2C module alias information ALSA: ppc: keywest: Export I2C module alias information hwmon: (nct7904) Export I2C module alias information regulator: fan53555: Export I2C module alias information mfd: Export OF module alias information in missing drivers iio: Export OF module alias information in missing drivers hwmon: (g762) Export OF module alias information extcon: Expor
Re: [PATCH v4] powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)
On Thu, 2015-07-30 at 07:47 +0300, Igal.Liberman wrote: > From: Igal Liberman > > Describe the PHY topology for all configurations supported by each board > > Based on prior work by Andy Fleming > > Signed-off-by: Igal Liberman > Signed-off-by: Shruti Kanetkar > Signed-off-by: Emil Medve Signoffs should be in chronological order. You were the last to touch/submit this, so yours should go last. Likewise in the other patches you just posted. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)
On Thu, 2015-07-30 at 07:33 +0300, Igal.Liberman wrote:
> @@ -307,4 +307,117 @@
> reg = <0xe 0x1000>;
> fsl,has-rstcr;
> };
> +
> + fman@10{
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <0>;
> + ranges = <0 0x10 0x10>;
> + compatible = "fsl,fman";
> + reg = <0x10 0x10>;
> + interrupts = <24 2 0 0>, <16 2 1 30>;
> + clock-frequency = <0>;
> + fsl,qman-channel-range = <0x40 0x7>;
fman is supposed to have clocks/clock-names, not clock-frequency.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
On Thu, 30 Jul 2015, Vlastimil Babka wrote: > > NAK. This is changing slob behavior. With no node specified it must use > > alloc_pages because that obeys NUMA memory policies etc etc. It should not > > force allocation from the current node like what is happening here after > > the patch. See the code in slub.c that is similar. > > Doh, somehow I convinced myself that there's #else and alloc_pages() is only > used for !CONFIG_NUMA so it doesn't matter. Here's a fixed version. Acked-by: Christoph Lameter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan
On Thu, 2015-07-30 at 07:32 +0300, Igal.Liberman wrote:
> +fman0: fman@40{
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <0>;
> + compatible = "fsl,fman";
> + ranges = <0 0x40 0x10>;
> + reg = <0x40 0x10>;
> + interrupts = <96 2 0 0>, <16 2 1 1>;
> + clocks = <&clockgen 3 0>;
> + clock-names = "fm0clk";
clock-names should be "fmanclk" as per the binding. And why would you want
the driver to have to encode the fman index into the name in order to look
the clock up by name?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
On 07/30/2015 07:58 PM, Christoph Lameter wrote:
> On Thu, 30 Jul 2015, Vlastimil Babka wrote:
>
>> --- a/mm/slob.c
>> +++ b/mm/slob.c
>> void *page;
>>
>> -#ifdef CONFIG_NUMA
>> -if (node != NUMA_NO_NODE)
>> -page = alloc_pages_exact_node(node, gfp, order);
>> -else
>> -#endif
>> -page = alloc_pages(gfp, order);
>> +page = alloc_pages_node(node, gfp, order);
>
> NAK. This is changing slob behavior. With no node specified it must use
> alloc_pages because that obeys NUMA memory policies etc etc. It should not
> force allocation from the current node like what is happening here after
> the patch. See the code in slub.c that is similar.
Doh, somehow I convinced myself that there's #else and alloc_pages() is only
used for !CONFIG_NUMA so it doesn't matter. Here's a fixed version.
--8<--
From: Vlastimil Babka
Date: Fri, 24 Jul 2015 15:49:47 +0200
Subject: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to
__alloc_pages_node
The function alloc_pages_exact_node() was introduced in 6484eb3e2a81 ("page
allocator: do not check NUMA node ID when the caller knows the node is valid")
as an optimized variant of alloc_pages_node(), that doesn't fallback to current
node for nid == NUMA_NO_NODE. Unfortunately the name of the function can easily
suggest that the allocation is restricted to the given node and fails
otherwise. In truth, the node is only preferred, unless __GFP_THISNODE is
passed among the gfp flags.
The misleading name has lead to mistakes in the past, see 5265047ac301 ("mm,
thp: really limit transparent hugepage allocation to local node") and
b360edb43f8e ("mm, mempolicy: migrate_to_node should only migrate to node").
Another issue with the name is that there's a family of alloc_pages_exact*()
functions where 'exact' means exact size (instead of page order), which leads
to more confusion.
To prevent further mistakes, this patch effectively renames
alloc_pages_exact_node() to __alloc_pages_node() to better convey that it's
an optimized variant of alloc_pages_node() not intended for general usage.
Both functions get described in comments.
It has been also considered to really provide a convenience function for
allocations restricted to a node, but the major opinion seems to be that
__GFP_THISNODE already provides that functionality and we shouldn't duplicate
the API needlessly. The number of users would be small anyway.
Existing callers of alloc_pages_exact_node() are simply converted to call
__alloc_pages_node(), with the exception of sba_alloc_coherent() which
open-codes the check for NUMA_NO_NODE, so it is converted to use
alloc_pages_node() instead. This means it no longer performs some VM_BUG_ON
checks, and since the current check for nid in alloc_pages_node() uses a 'nid <
0' comparison (which includes NUMA_NO_NODE), it may hide wrong values which
would be previously exposed. Both differences will be rectified by the next
patch.
To sum up, this patch makes no functional changes, except temporarily hiding
potentially buggy callers. Restricting the checks in alloc_pages_node() is
left for the next patch which can in turn expose more existing buggy callers.
Signed-off-by: Vlastimil Babka
Acked-by: Johannes Weiner
Cc: Mel Gorman
Cc: David Rientjes
Cc: Greg Thelen
Cc: Aneesh Kumar K.V
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: Joonsoo Kim
Cc: Naoya Horiguchi
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Acked-by: Michael Ellerman
Cc: Gleb Natapov
Cc: Paolo Bonzini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Cliff Whickman
Acked-by: Robin Holt
---
arch/ia64/hp/common/sba_iommu.c | 6 +-
arch/ia64/kernel/uncached.c | 2 +-
arch/ia64/sn/pci/pci_dma.c| 2 +-
arch/powerpc/platforms/cell/ras.c | 2 +-
arch/x86/kvm/vmx.c| 2 +-
drivers/misc/sgi-xp/xpc_uv.c | 2 +-
include/linux/gfp.h | 23 +++
kernel/profile.c | 8
mm/filemap.c | 2 +-
mm/huge_memory.c | 6 ++
mm/hugetlb.c | 4 ++--
mm/memory-failure.c | 2 +-
mm/mempolicy.c| 4 ++--
mm/migrate.c | 4 ++--
mm/page_alloc.c | 2 --
mm/slab.c | 2 +-
mm/slob.c | 4 ++--
mm/slub.c | 2 +-
18 files changed, 39 insertions(+), 40 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 344387a..a6d6190 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -1140,13 +1140,9 @@ sba_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle,
#ifdef CONFIG_NUMA
{
- int node = ioc->node;
struct page *page;
- if (node == NUMA_NO_NODE)
- node = nu
Re: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
On Thu, 30 Jul 2015, Vlastimil Babka wrote: > --- a/mm/slob.c > +++ b/mm/slob.c > void *page; > > -#ifdef CONFIG_NUMA > - if (node != NUMA_NO_NODE) > - page = alloc_pages_exact_node(node, gfp, order); > - else > -#endif > - page = alloc_pages(gfp, order); > + page = alloc_pages_node(node, gfp, order); NAK. This is changing slob behavior. With no node specified it must use alloc_pages because that obeys NUMA memory policies etc etc. It should not force allocation from the current node like what is happening here after the patch. See the code in slub.c that is similar. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] mm: unify checks in alloc_pages_node() and __alloc_pages_node()
Acked-by: Christoph Lameter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
On Thu, Jul 30, 2015 at 06:34:29PM +0200, Vlastimil Babka wrote:
> The function alloc_pages_exact_node() was introduced in 6484eb3e2a81 ("page
> allocator: do not check NUMA node ID when the caller knows the node is valid")
> as an optimized variant of alloc_pages_node(), that doesn't fallback to
> current
> node for nid == NUMA_NO_NODE. Unfortunately the name of the function can
> easily
> suggest that the allocation is restricted to the given node and fails
> otherwise. In truth, the node is only preferred, unless __GFP_THISNODE is
> passed among the gfp flags.
>
> The misleading name has lead to mistakes in the past, see 5265047ac301 ("mm,
> thp: really limit transparent hugepage allocation to local node") and
> b360edb43f8e ("mm, mempolicy: migrate_to_node should only migrate to node").
>
> Another issue with the name is that there's a family of alloc_pages_exact*()
> functions where 'exact' means exact size (instead of page order), which leads
> to more confusion.
>
> To prevent further mistakes, this patch effectively renames
> alloc_pages_exact_node() to __alloc_pages_node() to better convey that it's
> an optimized variant of alloc_pages_node() not intended for general usage.
> Both functions get described in comments.
>
> It has been also considered to really provide a convenience function for
> allocations restricted to a node, but the major opinion seems to be that
> __GFP_THISNODE already provides that functionality and we shouldn't duplicate
> the API needlessly. The number of users would be small anyway.
>
> Existing callers of alloc_pages_exact_node() are simply converted to call
> __alloc_pages_node(), with two exceptions. sba_alloc_coherent() and
> slob_new_page() both open-code the check for NUMA_NO_NODE, so they are
> converted to use alloc_pages_node() instead. This means they no longer perform
> some VM_BUG_ON checks, and since the current check for nid in
> alloc_pages_node() uses a 'nid < 0' comparison (which includes NUMA_NO_NODE),
> it may hide wrong values which would be previously exposed. Both differences
> will be rectified by the next patch.
>
> To sum up, this patch makes no functional changes, except temporarily hiding
> potentially buggy callers. Restricting the checks in alloc_pages_node() is
> left for the next patch which can in turn expose more existing buggy callers.
>
> Signed-off-by: Vlastimil Babka
> Cc: Mel Gorman
> Cc: David Rientjes
> Cc: Greg Thelen
> Cc: Aneesh Kumar K.V
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: Joonsoo Kim
> Cc: Naoya Horiguchi
> Cc: Tony Luck
> Cc: Fenghua Yu
> Cc: Arnd Bergmann
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Acked-by: Michael Ellerman
> Cc: Gleb Natapov
> Cc: Paolo Bonzini
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Cliff Whickman
> Acked-by: Robin Holt
Acked-by: Johannes Weiner
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] mm: unify checks in alloc_pages_node() and __alloc_pages_node()
On Thu, Jul 30, 2015 at 06:34:30PM +0200, Vlastimil Babka wrote: > Perform the same debug checks in alloc_pages_node() as are done in > __alloc_pages_node(), by making the former function a wrapper of the latter > one. > > In addition to better diagnostics in DEBUG_VM builds for situations which > have been already fatal (e.g. out-of-bounds node id), there are two visible > changes for potential existing buggy callers of alloc_pages_node(): > > - calling alloc_pages_node() with any negative nid (e.g. due to arithmetic > overflow) was treated as passing NUMA_NO_NODE and fallback to local node was > applied. This will now be fatal. > - calling alloc_pages_node() with an offline node will now be checked for > DEBUG_VM builds. Since it's not fatal if the node has been previously > online, > and this patch may expose some existing buggy callers, change the VM_BUG_ON > in __alloc_pages_node() to VM_WARN_ON. > > Signed-off-by: Vlastimil Babka > Acked-by: David Rientjes Acked-by: Johannes Weiner ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()
On Thu, 30 Jul 2015, Vlastimil Babka wrote: > numa_mem_id() is able to handle allocation from CPUs on memory-less nodes, > so it's a more robust fallback than the currently used numa_node_id(). > > Suggested-by: Christoph Lameter > Signed-off-by: Vlastimil Babka > Acked-by: David Rientjes > Acked-by: Mel Gorman You can add my ack too if it helps. Acked-by: Christoph Lameter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()
On Thu, Jul 30, 2015 at 06:34:31PM +0200, Vlastimil Babka wrote: > numa_mem_id() is able to handle allocation from CPUs on memory-less nodes, > so it's a more robust fallback than the currently used numa_node_id(). Won't it fall through to the next closest memory node in the zonelist anyway? Is this for callers doing NUMA_NO_NODE with __GFP_THISZONE? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to genalloc
On Wed, 2015-07-29 at 20:27 -0500, Zhao Qiang-B45475 wrote: > On Thu, 2015-07-30 at 5:21, Scott Wood wrote: > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Thursday, July 30, 2015 12:19 AM > > To: Zhao Qiang-B45475 > > Cc: lau...@codeaurora.org; linux-ker...@vger.kernel.org; linuxppc- > > d...@lists.ozlabs.org; a...@linux-foundation.org; o...@lixom.net; > > catalin.mari...@arm.com; Xie Xiaobo-R63061 > > Subject: Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo to > > genalloc > > > > On Tue, 2015-07-28 at 00:32 -0500, Zhao Qiang-B45475 wrote: > > > On Tue, 2015-07-28 at 5:21, Scott Wood wrote: > > > > -Original Message- > > > > From: Wood Scott-B07421 > > > > Sent: Tuesday, July 28, 2015 5:21 AM > > > > To: Zhao Qiang-B45475 > > > > Cc: lau...@codeaurora.org; linux-ker...@vger.kernel.org; linuxppc- > > > > d...@lists.ozlabs.org; a...@linux-foundation.org; o...@lixom.net; > > > > catalin.mari...@arm.com; Xie Xiaobo-R63061 > > > > Subject: Re: [RFC v2] genalloc:add an gen_pool_first_fit_align algo > > > > to genalloc > > > > > > > > On Mon, 2015-07-27 at 17:57 +0800, Zhao Qiang wrote: > > > > > > > > Where's the part that adds the ability to pass in data to each > > > > allocation call, as per the previous discussion? > > > > > > You means to use gen_pool_alloc_data()? > > > > Yes. > > > > > Previously you said that the format of data is algorithm-specific, So > > > I think it is better to handle data in algorithm function. > > > > It is a channel for communication from the API caller to the algorithm. > > > > > If you still prefer gen_pool_alloc_data(), I will modify it. > > > But there still are details I want to confirm with you. > > > 1. If use gen_pool_alloc_data(), should I pass data as a parameter? > > > > Yes. > > > > > 2. Should I count align_mask in gen_pool_alloc_data(), meanwhile, add > > >a align_mask to data as a member? > > > > gen_pool_alloc_data() should just pass data to the algorithm. The > > algorithm should calculate align_mask based on align. I don't think > > exposing align_mask to API users would be very friendly. > > If calculate align_mask in algorithm, I need to get pool->min_alloc_order > in algorithm, > Like: >order = data->pool->min_alloc_order; >align_mask = ((data->align + (1UL << order) - 1) >> order) - > 1; > so I add pool to structure data as a member. Is there any other better > idea? Pass pool as a parameter to the algorithm. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/kernel: Enable seccomp filter
On Wed, Jul 29, 2015 at 10:56 PM, Michael Ellerman wrote: > This commit enables seccomp filter on powerpc, now that we have all the > necessary pieces in place. > > To support seccomp's desire to modify the syscall return value under > some circumstances, we use a different ABI to the ptrace ABI. That is we > use r3 as the syscall return value, and orig_gpr3 is the first syscall > parameter. > > This means the seccomp code, or a ptracer via SECCOMP_RET_TRACE, will > see -ENOSYS preloaded in r3. This is identical to the behaviour on x86, > and allows seccomp or the ptracer to either leave the -ENOSYS or change > it to something else, as well as rejecting or not the syscall by > modifying r0. > > If seccomp does not reject the syscall, we restore the register state to > match what ptrace and audit expect, ie. r3 is the first syscall > parameter again. We do this restore using orig_gpr3, which may have been > modified by seccomp, which allows seccomp to modify the first syscall > paramater and allow the syscall to proceed. > > We need to #ifdef the the additional handling of r3 for seccomp, so move > it all out of line. > > Signed-off-by: Michael Ellerman > Reviewed-by: Kees Cook > --- > arch/powerpc/Kconfig | 1 + > arch/powerpc/kernel/ptrace.c | 41 - > 2 files changed, 41 insertions(+), 1 deletion(-) > > > v2: The previous version didn't compile for CONFIG_SECCOMP=n. To fix it up I > moved the logic out of line and #ifdef'ed that. It gets inlined by the > compiler > so the end result is the same. > > Kees I kept your Reviewed-by on the basis that the interesting logic is > the > same, hope that's OK by you. Totally fine. Thanks! -Kees -- Kees Cook Chrome OS Security ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers
On Thu, Jul 30, 2015 at 09:35:17AM -0700, Dmitry Torokhov wrote: > Hi Javier, > > On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: > > Hello, > > > > Short version: > > > > This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables > > to export that information so modules have the correct aliases built-in > > and autoloading works correctly. > > > > Longer version: > > > > Currently it's mandatory for I2C drivers to have an I2C device ID table > > regardless if the device was registered using platform data or OF. This > > is because the I2C core needs an I2C device ID table for two reasons: > > > > 1) Match the I2C client with a I2C device ID so a struct i2c_device_id > >is passed to the I2C driver probe() function. > > > > 2) Export the module aliases from the I2C device ID table so userspace > >can auto-load the correct module. This is because i2c_device_uevent > >always reports a MODALIAS of the form i2c:name>. > > Why are we not fixing this? We emit specially carved uevent for > ACPI-based devices, why not the same for OF? Platform bus does this... Ah, now I see the 27/27 patch. I think it is exactly what we need. And probably for SPI bus as well. Thanks. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/27] Export I2C and OF module aliases in missing drivers
Hi Javier, On Thu, Jul 30, 2015 at 06:18:25PM +0200, Javier Martinez Canillas wrote: > Hello, > > Short version: > > This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables > to export that information so modules have the correct aliases built-in > and autoloading works correctly. > > Longer version: > > Currently it's mandatory for I2C drivers to have an I2C device ID table > regardless if the device was registered using platform data or OF. This > is because the I2C core needs an I2C device ID table for two reasons: > > 1) Match the I2C client with a I2C device ID so a struct i2c_device_id >is passed to the I2C driver probe() function. > > 2) Export the module aliases from the I2C device ID table so userspace >can auto-load the correct module. This is because i2c_device_uevent >always reports a MODALIAS of the form i2c:name>. Why are we not fixing this? We emit specially carved uevent for ACPI-based devices, why not the same for OF? Platform bus does this... Thanks. -- Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/3] mm: rename alloc_pages_exact_node to __alloc_pages_node
The function alloc_pages_exact_node() was introduced in 6484eb3e2a81 ("page
allocator: do not check NUMA node ID when the caller knows the node is valid")
as an optimized variant of alloc_pages_node(), that doesn't fallback to current
node for nid == NUMA_NO_NODE. Unfortunately the name of the function can easily
suggest that the allocation is restricted to the given node and fails
otherwise. In truth, the node is only preferred, unless __GFP_THISNODE is
passed among the gfp flags.
The misleading name has lead to mistakes in the past, see 5265047ac301 ("mm,
thp: really limit transparent hugepage allocation to local node") and
b360edb43f8e ("mm, mempolicy: migrate_to_node should only migrate to node").
Another issue with the name is that there's a family of alloc_pages_exact*()
functions where 'exact' means exact size (instead of page order), which leads
to more confusion.
To prevent further mistakes, this patch effectively renames
alloc_pages_exact_node() to __alloc_pages_node() to better convey that it's
an optimized variant of alloc_pages_node() not intended for general usage.
Both functions get described in comments.
It has been also considered to really provide a convenience function for
allocations restricted to a node, but the major opinion seems to be that
__GFP_THISNODE already provides that functionality and we shouldn't duplicate
the API needlessly. The number of users would be small anyway.
Existing callers of alloc_pages_exact_node() are simply converted to call
__alloc_pages_node(), with two exceptions. sba_alloc_coherent() and
slob_new_page() both open-code the check for NUMA_NO_NODE, so they are
converted to use alloc_pages_node() instead. This means they no longer perform
some VM_BUG_ON checks, and since the current check for nid in
alloc_pages_node() uses a 'nid < 0' comparison (which includes NUMA_NO_NODE),
it may hide wrong values which would be previously exposed. Both differences
will be rectified by the next patch.
To sum up, this patch makes no functional changes, except temporarily hiding
potentially buggy callers. Restricting the checks in alloc_pages_node() is
left for the next patch which can in turn expose more existing buggy callers.
Signed-off-by: Vlastimil Babka
Cc: Mel Gorman
Cc: David Rientjes
Cc: Greg Thelen
Cc: Aneesh Kumar K.V
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: Joonsoo Kim
Cc: Naoya Horiguchi
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Acked-by: Michael Ellerman
Cc: Gleb Natapov
Cc: Paolo Bonzini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Cliff Whickman
Acked-by: Robin Holt
---
Based on feedback from v1 and v2, The name is __alloc_pages_node() instead of
alloc_pages_prefer_node() from v1. Two callsites were also converted to
alloc_pages_node() instead. v2 was a RFC for linux-mm to settle on the API
first. It tried keeping alloc_pages_exact_node() as a wrapper that adds
__GFP_THISNODE but the consensus was to drop it.
I'm CC'ing also maintainers of the callsites so they can verify that the
callsites that don't pass __GFP_THISNODE are really not intended to restrict
allocation to the given node. I went through them myself and each looked like
it's better off if it can successfully allocate on a fallback node rather
than fail. DavidR checked them also I think, but it's better if maintainers
can verify that. I'm not completely sure about all the usages in sl*b due to
multiple layers through which gfp flags are being passed.
Patches 2 and 3 are mm-only so I don't CC everyone.
arch/ia64/hp/common/sba_iommu.c | 6 +-
arch/ia64/kernel/uncached.c | 2 +-
arch/ia64/sn/pci/pci_dma.c| 2 +-
arch/powerpc/platforms/cell/ras.c | 2 +-
arch/x86/kvm/vmx.c| 2 +-
drivers/misc/sgi-xp/xpc_uv.c | 2 +-
include/linux/gfp.h | 23 +++
kernel/profile.c | 8
mm/filemap.c | 2 +-
mm/huge_memory.c | 6 ++
mm/hugetlb.c | 4 ++--
mm/memory-failure.c | 2 +-
mm/mempolicy.c| 4 ++--
mm/migrate.c | 4 ++--
mm/page_alloc.c | 2 --
mm/slab.c | 2 +-
mm/slob.c | 14 --
mm/slub.c | 2 +-
18 files changed, 41 insertions(+), 48 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 344387a..a6d6190 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -1140,13 +1140,9 @@ sba_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle,
#ifdef CONFIG_NUMA
{
- int node = ioc->node;
struct page *page;
- if (node == NUMA_NO_NODE)
- node = numa_node_id();
-
- page = alloc_pages_exact_node
[PATCH v3 3/3] mm: use numa_mem_id() in alloc_pages_node()
numa_mem_id() is able to handle allocation from CPUs on memory-less nodes,
so it's a more robust fallback than the currently used numa_node_id().
Suggested-by: Christoph Lameter
Signed-off-by: Vlastimil Babka
Acked-by: David Rientjes
Acked-by: Mel Gorman
---
include/linux/gfp.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 4a12cae2..f92cbd2 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -318,13 +318,14 @@ __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int
order)
/*
* Allocate pages, preferring the node given as nid. When nid == NUMA_NO_NODE,
- * prefer the current CPU's node. Otherwise node must be valid and online.
+ * prefer the current CPU's closest node. Otherwise node must be valid and
+ * online.
*/
static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
unsigned int order)
{
if (nid == NUMA_NO_NODE)
- nid = numa_node_id();
+ nid = numa_mem_id();
return __alloc_pages_node(nid, gfp_mask, order);
}
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/3] mm: unify checks in alloc_pages_node() and __alloc_pages_node()
Perform the same debug checks in alloc_pages_node() as are done in
__alloc_pages_node(), by making the former function a wrapper of the latter
one.
In addition to better diagnostics in DEBUG_VM builds for situations which
have been already fatal (e.g. out-of-bounds node id), there are two visible
changes for potential existing buggy callers of alloc_pages_node():
- calling alloc_pages_node() with any negative nid (e.g. due to arithmetic
overflow) was treated as passing NUMA_NO_NODE and fallback to local node was
applied. This will now be fatal.
- calling alloc_pages_node() with an offline node will now be checked for
DEBUG_VM builds. Since it's not fatal if the node has been previously online,
and this patch may expose some existing buggy callers, change the VM_BUG_ON
in __alloc_pages_node() to VM_WARN_ON.
Signed-off-by: Vlastimil Babka
Acked-by: David Rientjes
---
v3: I think this is enough for what patch 4/4 in v2 tried to provide on top,
so there's no patch 4/4 anymore. The DEBUG_VM-only fixup didn't seem
justified to me.
include/linux/gfp.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index d2c142b..4a12cae2 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -310,23 +310,23 @@ __alloc_pages(gfp_t gfp_mask, unsigned int order,
static inline struct page *
__alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
{
- VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
+ VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
+ VM_WARN_ON(!node_online(nid));
return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
}
/*
* Allocate pages, preferring the node given as nid. When nid == NUMA_NO_NODE,
- * prefer the current CPU's node.
+ * prefer the current CPU's node. Otherwise node must be valid and online.
*/
static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,
unsigned int order)
{
- /* Unknown node is current node */
- if (nid < 0)
+ if (nid == NUMA_NO_NODE)
nid = numa_node_id();
- return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));
+ return __alloc_pages_node(nid, gfp_mask, order);
}
#ifdef CONFIG_NUMA
--
2.4.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH 8/8] powerpc/fsl: Use new clockgen binding
Regards, Igal Liberman. > -Original Message- > From: Wood Scott-B07421 > Sent: Friday, June 19, 2015 5:49 AM > To: Mike Turquette; Tang Yuantian-B29983 > Cc: Rafael J. Wysocki; Liberman Igal-B31950; Bucur Madalin-Cristian-B32716; > linux-...@vger.kernel.org; linux...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; Wood Scott-B07421 > Subject: [RFC PATCH 8/8] powerpc/fsl: Use new clockgen binding > > The driver retains compatibility with old device trees, but we don't want the > old nodes lying around to be copied, or used as a reference (some of the > mux options are incorrect), or even just being clutter. > > We will also need the #clock-cells in the clockgen node in order to add fman > nodes. > > Signed-off-by: Scott Wood > --- Tested on: several e500mc, e5500 and e6500 platforms. Tested-by: Igal Liberman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] ASoC: fsl_ssi: enable IPG clock during AC'97 reg access
Hi Fabio,
On 30.07.2015 17:20, Fabio Estevam wrote:
> Hi Maciej,
>
> On Thu, Jul 30, 2015 at 11:33 AM, Maciej S. Szmigiero
> wrote:
>
>> static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
>> @@ -1151,6 +1160,14 @@ static unsigned short fsl_ssi_ac97_read(struct
>> snd_ac97 *ac97,
>> unsigned short val = -1;
>> u32 reg_val;
>> unsigned int lreg;
>> + int ret;
>> +
>> + ret = clk_prepare_enable(fsl_ac97_data->clk);
>> + if (ret) {
>> + pr_err("ac97 read clk_prepare_enable failed: %d\n",
>> + ret);
>> + return -1;
>
> return ret, please.
>
This function normal return value is an AC'97 register value,
so isn't more appropriate to return 0x in case of error
than linux error code?
Best regards,
Maciej Szmigiero
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] ASoC: fsl_ssi: enable IPG clock during AC'97 reg access
Hi Maciej,
On Thu, Jul 30, 2015 at 11:33 AM, Maciej S. Szmigiero
wrote:
> static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
> @@ -1151,6 +1160,14 @@ static unsigned short fsl_ssi_ac97_read(struct
> snd_ac97 *ac97,
> unsigned short val = -1;
> u32 reg_val;
> unsigned int lreg;
> + int ret;
> +
> + ret = clk_prepare_enable(fsl_ac97_data->clk);
> + if (ret) {
> + pr_err("ac97 read clk_prepare_enable failed: %d\n",
> + ret);
> + return -1;
return ret, please.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/6] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
Adjust set DAI format function in fsl_ssi driver so it
doesn't fail and clears RXDIR in AC'97 mode.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 8e5ff5e..37aabe3 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -900,14 +900,16 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
scr &= ~CCSR_SSI_SCR_SYS_CLK_EN;
break;
default:
- return -EINVAL;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ return -EINVAL;
}
stcr |= strcr;
srcr |= strcr;
- if (ssi_private->cpu_dai_drv.symmetric_rates) {
- /* Need to clear RXDIR when using SYNC mode */
+ if (ssi_private->cpu_dai_drv.symmetric_rates
+ || fsl_ssi_is_ac97(ssi_private)) {
+ /* Need to clear RXDIR when using SYNC or AC97 mode */
srcr &= ~CCSR_SSI_SRCR_RXDIR;
scr |= CCSR_SSI_SCR_SYN;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/6] ASoC: fsl_ssi: instantiate AC'97 CODEC
Instantiate AC'97 CODEC in fsl_ssi driver AC'97 mode.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 154bcf6..8e5ff5e 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1460,6 +1460,27 @@ done:
_fsl_ssi_set_dai_fmt(&pdev->dev, ssi_private,
ssi_private->dai_fmt);
+ if (fsl_ssi_is_ac97(ssi_private)) {
+ u32 ssi_idx;
+
+ ret = of_property_read_u32(np, "cell-index", &ssi_idx);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot get SSI index property\n");
+ goto error_sound_card;
+ }
+
+ ssi_private->pdev =
+ platform_device_register_data(NULL,
+ "ac97-codec", ssi_idx, NULL, 0);
+ if (IS_ERR(ssi_private->pdev)) {
+ ret = PTR_ERR(ssi_private->pdev);
+ dev_err(&pdev->dev,
+ "failed to register AC97 codec platform: %d\n",
+ ret);
+ goto error_sound_card;
+ }
+ }
+
return 0;
error_sound_card:
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/6] ASoC: fsl_ssi: add AC'97 ops setting check and cleanup
Check whether setting AC'97 ops succeeded and clean them
on removal so the fsl_ssi driver can be reloaded.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 7f4f0b9..154bcf6 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1340,7 +1340,11 @@ static int fsl_ssi_probe(struct platform_device *pdev)
fsl_ac97_data = ssi_private;
- snd_soc_set_ac97_ops_of_reset(&fsl_ssi_ac97_ops, pdev);
+ ret = snd_soc_set_ac97_ops_of_reset(&fsl_ssi_ac97_ops, pdev);
+ if (ret) {
+ dev_err(&pdev->dev, "could not set AC'97 ops\n");
+ return ret;
+ }
} else {
/* Initialize this copy of the CPU DAI driver structure */
memcpy(&ssi_private->cpu_dai_drv, &fsl_ssi_dai_template,
@@ -1480,6 +1484,9 @@ static int fsl_ssi_remove(struct platform_device *pdev)
if (ssi_private->soc->imx)
fsl_ssi_imx_clean(pdev, ssi_private);
+ if (fsl_ssi_is_ac97(ssi_private))
+ snd_soc_set_ac97_ops(NULL);
+
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
AC'97 bus can support asymmetric playback/capture rates
so enable them in this case in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index a83b900..7f4f0b9 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
- ssi_private->cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private->cpu_dai_drv.symmetric_rates = 1;
+
ssi_private->cpu_dai_drv.symmetric_channels = 1;
ssi_private->cpu_dai_drv.symmetric_samplebits = 1;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/6] ASoC: fsl_ssi: AC'97 DAI driver needs probe method too
AC'97 DAI driver struct need the same probe method as
I2S one to setup DMA params in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 8185edc..a83b900 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1101,6 +1101,7 @@ static const struct snd_soc_component_driver
fsl_ssi_component = {
static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
.bus_control = true,
+ .probe = fsl_ssi_dai_probe,
.playback = {
.stream_name = "AC97 Playback",
.channels_min = 2,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] ASoC: fsl_ssi: enable IPG clock during AC'97 reg access
IPG clock have to be enabled during AC'97 CODEC register
access in fsl_ssi driver.
Signed-off-by: Maciej Szmigiero
---
sound/soc/fsl/fsl_ssi.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 484ff20..8185edc 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1127,10 +1127,17 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97,
unsigned short reg,
struct regmap *regs = fsl_ac97_data->regs;
unsigned int lreg;
unsigned int lval;
+ int ret;
if (reg > 0x7f)
return;
+ ret = clk_prepare_enable(fsl_ac97_data->clk);
+ if (ret) {
+ pr_err("ac97 write clk_prepare_enable failed: %d\n",
+ ret);
+ return;
+ }
lreg = reg << 12;
regmap_write(regs, CCSR_SSI_SACADD, lreg);
@@ -1141,6 +1148,8 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97,
unsigned short reg,
regmap_update_bits(regs, CCSR_SSI_SACNT, CCSR_SSI_SACNT_RDWR_MASK,
CCSR_SSI_SACNT_WR);
udelay(100);
+
+ clk_disable_unprepare(fsl_ac97_data->clk);
}
static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
@@ -1151,6 +1160,14 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97
*ac97,
unsigned short val = -1;
u32 reg_val;
unsigned int lreg;
+ int ret;
+
+ ret = clk_prepare_enable(fsl_ac97_data->clk);
+ if (ret) {
+ pr_err("ac97 read clk_prepare_enable failed: %d\n",
+ ret);
+ return -1;
+ }
lreg = (reg & 0x7f) << 12;
regmap_write(regs, CCSR_SSI_SACADD, lreg);
@@ -1162,6 +1179,8 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97
*ac97,
regmap_read(regs, CCSR_SSI_SACDAT, ®_val);
val = (reg_val >> 4) & 0x;
+ clk_disable_unprepare(fsl_ac97_data->clk);
+
return val;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 04/46] staging: emxx_udc: add ep capabilities support
Hi,
On Thu, Jul 30, 2015 at 09:15:38AM +0200, Robert Baldyga wrote:
> On 07/29/2015 05:20 PM, Felipe Balbi wrote:
> > On Mon, Jul 27, 2015 at 11:16:14AM +0200, Robert Baldyga wrote:
> >> Convert endpoint configuration to new capabilities model.
> >>
> >> Fixed typo in "epc-nulk" to "epc-bulk".
> >>
> >> Signed-off-by: Robert Baldyga
> >> ---
> >> drivers/staging/emxx_udc/emxx_udc.c | 60
> >> ++---
> >> 1 file changed, 29 insertions(+), 31 deletions(-)
> >>
> >> diff --git a/drivers/staging/emxx_udc/emxx_udc.c
> >> b/drivers/staging/emxx_udc/emxx_udc.c
> >> index 3b7aa36..0d64bee 100644
> >> --- a/drivers/staging/emxx_udc/emxx_udc.c
> >> +++ b/drivers/staging/emxx_udc/emxx_udc.c
> >> @@ -3153,36 +3153,33 @@ static const struct usb_gadget_ops
> >> nbu2ss_gadget_ops = {
> >>.ioctl = nbu2ss_gad_ioctl,
> >> };
> >>
> >> -static const char g_ep0_name[] = "ep0";
> >> -static const char g_ep1_name[] = "ep1-bulk";
> >> -static const char g_ep2_name[] = "ep2-bulk";
> >> -static const char g_ep3_name[] = "ep3in-int";
> >> -static const char g_ep4_name[] = "ep4-iso";
> >> -static const char g_ep5_name[] = "ep5-iso";
> >> -static const char g_ep6_name[] = "ep6-bulk";
> >> -static const char g_ep7_name[] = "ep7-bulk";
> >> -static const char g_ep8_name[] = "ep8in-int";
> >> -static const char g_ep9_name[] = "ep9-iso";
> >> -static const char g_epa_name[] = "epa-iso";
> >> -static const char g_epb_name[] = "epb-bulk";
> >> -static const char g_epc_name[] = "epc-nulk";
> >> -static const char g_epd_name[] = "epdin-int";
> >> -
> >> -static const char *gp_ep_name[NUM_ENDPOINTS] = {
> >> - g_ep0_name,
> >> - g_ep1_name,
> >> - g_ep2_name,
> >> - g_ep3_name,
> >> - g_ep4_name,
> >> - g_ep5_name,
> >> - g_ep6_name,
> >> - g_ep7_name,
> >> - g_ep8_name,
> >> - g_ep9_name,
> >> - g_epa_name,
> >> - g_epb_name,
> >> - g_epc_name,
> >> - g_epd_name,
> >> +static const struct {
> >> + const char *name;
> >> + const struct usb_ep_caps caps;
> >> +} ep_info[NUM_ENDPOINTS] = {
> >> +#define EP_INFO(_name, _type, _dir) \
> >> + { \
> >> + .name = _name, \
> >> + .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
> >> + USB_EP_CAPS_DIR_ ## _dir), \
> >> + }
> >> +
> >> + EP_INFO("ep0", CONTROL, ALL),
> >> + EP_INFO("ep1-bulk", BULK, ALL),
> >> + EP_INFO("ep2-bulk", BULK, ALL),
> >> + EP_INFO("ep3in-int",INT,IN),
> >> + EP_INFO("ep4-iso", INT,ALL),
> >> + EP_INFO("ep5-iso", ISO,ALL),
> >> + EP_INFO("ep6-bulk", ISO,ALL),
> >> + EP_INFO("ep7-bulk", BULK, ALL),
> >> + EP_INFO("ep8in-int",INT,IN),
> >> + EP_INFO("ep9-iso", ISO,ALL),
> >> + EP_INFO("epa-iso", ISO,ALL),
> >> + EP_INFO("epb-bulk", BULK, ALL),
> >> + EP_INFO("epc-bulk", BULK, ALL),
> >> + EP_INFO("epdin-int",INT,IN),
> >
> > IMO, this is pointless obfuscation. It just makes it a pain to grep
> > source around. Why don't you have UDC drivers initialize the 1-bit flags
> > directly ?
> >
>
> Do you mean something like this? It just makes it a pain to scroll this
> source ;)
but it's at least easy to grep. Another option would be the following:
EP_INFO("ep0", USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
USB_EP_CAPS_DIR_ALL)),
that also helps grepping.
--
balbi
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -v2 6/8] jump_label: Add a new static_key interface
On Tue, 2015-07-28 at 15:21 +0200, Peter Zijlstra wrote: > There are various problems and short-comings with the current > static_key interface: ... > --- > arch/powerpc/include/asm/jump_label.h | 19 This looks sane and seems to be working, so powerpc bits: Acked-by: Michael Ellerman cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/fsl-pci: fix pcie range issue for some P1/P2 boards
Hi Scott, > -Original Message- > From: Wood Scott-B07421 > Sent: 2015年7月29日 10:35 > To: Hou Zhiqiang-B48286 > Cc: linuxppc-dev@lists.ozlabs.org; b...@kernel.crashing.org; > pau...@samba.org; m...@ellerman.id.au; Hu Mingkai-B21284 > Subject: Re: [PATCH] powerpc/fsl-pci: fix pcie range issue for some P1/P2 > boards > > On Tue, 2015-07-28 at 21:34 -0500, Hou Zhiqiang-B48286 wrote: > > Hi Scott and all, > > > > Please ignore this patch! > > Did you figure out what was actually causing you to see CPU stalls? > This issue fixed by cf4d1cf5ac5e7d2b886af6ed906ea0dcdc5b6855 in upstream. > -Scott Thanks, Zhiqiang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4] powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)
From: Igal Liberman
Describe the PHY topology for all configurations supported by each board
Based on prior work by Andy Fleming
Signed-off-by: Igal Liberman
Signed-off-by: Shruti Kanetkar
Signed-off-by: Emil Medve
---
Depends on the following patch set:
https://patchwork.ozlabs.org/patch/502018/
https://patchwork.ozlabs.org/patch/502019/
v3 ---> v4:
- Added T1024 support
v2 ---> v3:
- Fixed incorrect E-Mail address (signed-off-by)
v1 ---> v2
- Remove 'Change-Id'
arch/powerpc/boot/dts/b4860qds.dts| 60 -
arch/powerpc/boot/dts/b4qds.dtsi | 51 -
arch/powerpc/boot/dts/p1023rdb.dts| 24 +-
arch/powerpc/boot/dts/p2041rdb.dts| 92 +++-
arch/powerpc/boot/dts/p3041ds.dts | 112 -
arch/powerpc/boot/dts/p4080ds.dts | 184 ++-
arch/powerpc/boot/dts/p5020ds.dts | 112 -
arch/powerpc/boot/dts/p5040ds.dts | 234 ++-
arch/powerpc/boot/dts/t1023rdb.dts| 41
arch/powerpc/boot/dts/t1024rdb.dts| 45
arch/powerpc/boot/dts/t1040rdb.dts| 32 ++-
arch/powerpc/boot/dts/t1042rdb.dts| 30 ++-
arch/powerpc/boot/dts/t1042rdb_pi.dts | 18 +-
arch/powerpc/boot/dts/t104xqds.dtsi | 178 ++-
arch/powerpc/boot/dts/t104xrdb.dtsi | 33 ++-
arch/powerpc/boot/dts/t2080qds.dts| 158 -
arch/powerpc/boot/dts/t2080rdb.dts| 67 +-
arch/powerpc/boot/dts/t2081qds.dts| 221 +-
arch/powerpc/boot/dts/t4240qds.dts| 400 -
arch/powerpc/boot/dts/t4240rdb.dts| 149 +++-
20 files changed, 2221 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4860qds.dts
b/arch/powerpc/boot/dts/b4860qds.dts
index 6bb3707..98b1ef4 100644
--- a/arch/powerpc/boot/dts/b4860qds.dts
+++ b/arch/powerpc/boot/dts/b4860qds.dts
@@ -1,7 +1,7 @@
/*
* B4860DS Device Tree Source
*
- * Copyright 2012 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -39,12 +39,69 @@
model = "fsl,B4860QDS";
compatible = "fsl,B4860QDS";
+ aliases {
+ phy_sgmii_1e = &phy_sgmii_1e;
+ phy_sgmii_1f = &phy_sgmii_1f;
+ phy_xaui_slot1 = &phy_xaui_slot1;
+ phy_xaui_slot2 = &phy_xaui_slot2;
+ };
+
ifc: localbus@ffe124000 {
board-control@3,0 {
compatible = "fsl,b4860qds-fpga", "fsl,fpga-qixis";
};
};
+ soc@ffe00 {
+ fman@40 {
+ ethernet@e8000 {
+ phy-handle = <&phy_sgmii_1e>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@ea000 {
+ phy-handle = <&phy_sgmii_1f>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@f {
+ phy-handle = <&phy_xaui_slot1>;
+ phy-connection-type = "xgmii";
+ };
+
+ ethernet@f2000 {
+ phy-handle = <&phy_xaui_slot2>;
+ phy-connection-type = "xgmii";
+ };
+
+ mdio@fc000 {
+ phy_sgmii_1e: ethernet-phy@1e {
+ reg = <0x1e>;
+ status = "disabled";
+ };
+
+ phy_sgmii_1f: ethernet-phy@1f {
+ reg = <0x1f>;
+ status = "disabled";
+ };
+ };
+
+ mdio@fd000 {
+ phy_xaui_slot1: xaui-phy@slot1 {
+ compatible =
"ethernet-phy-ieee802.3-c45";
+ reg = <0x7>;
+ status = "disabled";
+ };
+
+ phy_xaui_slot2: xaui-phy@slot2 {
+ compatible =
"ethernet-phy-ieee802.3-c45";
+ reg = <0x6>;
+ status = "disabled";
+ };
+ };
+ };
+ };
+
rio: rapidio@ffe0c {
reg = <0xf 0xfe0c 0 0x11000>;
@@ -55,7 +112,6 @@
ranges = <0 0 0xc 0x3000 0 0x1000>;
};
};
-
};
/include/ "fsl/b4860si-post.dtsi"
diff --git a/arch/
[PATCH v2 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)
From: Igal Liberman
Based on prior work by Andy Fleming
Signed-off-by: Igal Liberman
Signed-off-by: Shruti Kanetkar
Signed-off-by: Emil Medve
---
v1 ---> v2:
- Added T1024 support
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi |9 ++-
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 20 -
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 12 ++-
arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 31 +++-
arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 115 ++-
arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi |5 +-
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 29 ++-
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 10 ++-
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 29 ++-
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 10 ++-
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 48 ++-
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 15 +++-
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 29 ++-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 10 ++-
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 56 -
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 17 +++-
arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 19 +
arch/powerpc/boot/dts/fsl/t102xsi-pre.dtsi |6 ++
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 31
arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi |9 ++-
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 43 ++
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 11 +++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 88 +++-
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 22 -
24 files changed, 654 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index 9cfeaef..5d54ec7 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -1,7 +1,7 @@
/*
* B4420 Silicon/SoC Device Tree Source (pre include)
*
- * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor, Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -54,8 +54,13 @@
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
- };
+ fman0 = &fman0;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ ethernet3 = &enet3;
+ };
cpus {
#address-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index 26585d6..3065833 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -1,7 +1,7 @@
/*
* B4860 Silicon/SoC Device Tree Source (post include)
*
- * Copyright 2012 - 2014 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -271,6 +271,24 @@
compatible = "fsl,b4860-rcpm", "fsl,qoriq-rcpm-2.0";
};
+/include/ "qoriq-fman3-0-1g-4.dtsi"
+/include/ "qoriq-fman3-0-1g-5.dtsi"
+/include/ "qoriq-fman3-0-10g-0.dtsi"
+/include/ "qoriq-fman3-0-10g-1.dtsi"
+ fman@40 {
+ enet4: ethernet@e8000 {
+ };
+
+ enet5: ethernet@ea000 {
+ };
+
+ enet6: ethernet@f {
+ };
+
+ enet7: ethernet@f2000 {
+ };
+ };
+
L2: l2-cache-controller@c2 {
compatible = "fsl,b4860-l2-cache-controller";
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
index bc914f2..a738f7c 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
@@ -1,7 +1,7 @@
/*
* B4860 Silicon/SoC Device Tree Source (pre include)
*
- * Copyright 2012 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -54,6 +54,16 @@
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
+
+ fman0 = &fman0;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ ethernet3 = &enet3;
+ ethernet4 = &enet4;
+ ethernet5 = &enet5;
+ ethernet6 = &enet6;
+ ethernet7 = &enet7;
};
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 164fdfc..d51e2bb 100644
--- a/arch/p
RE: [PATCH V2] QorIQ/TMU: add thermal management support based on TMU
- "Any specific reason why not using OF thermal?"
- No, actually.
I'd like to use OF thermal after some clarification.
Regarding to "cooling-maps". For some cases there should be more than one cpus
as cooling device and they are independent.
1. Let's say 4. So we need to provide 4 maps like map0-map3. Right?
2. "cooling-max-level" may vary depend on switch settings or firmware. Is that
OK if I do not provide "cooling-min-level" and "cooling-max-level" property?
Thanks.
-Hongtao
> -Original Message-
> From: Eduardo Valentin [mailto:edubez...@gmail.com]
> Sent: Thursday, July 30, 2015 2:56 PM
> To: Jia Hongtao-B38951
> Cc: linux...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Wood Scott-
> B07421
> Subject: Re: [PATCH V2] QorIQ/TMU: add thermal management support based
> on TMU
>
> On Wed, Jul 29, 2015 at 02:19:39PM +0800, Jia Hongtao wrote:
> > It supports one critical trip point and one passive trip point.
> > The cpufreq is used as the cooling device to throttle CPUs when the
> > passive trip is crossed.
> >
> > Signed-off-by: Jia Hongtao
> > ---
> > This patch based on:
> > http://patchwork.ozlabs.org/patch/482987/
> >
> > Changes for V2:
> > * Add tmu-range parse.
> > * Use default trend hook.
> > * Using latest thermal_zone_bind_cooling_device API.
> > * Add calibration check during initialization.
> > * Disable/enalbe device when suspend/resume.
> >
> > drivers/thermal/Kconfig | 11 ++
> > drivers/thermal/Makefile| 1 +
> > drivers/thermal/qoriq_thermal.c | 406
> >
> > 3 files changed, 418 insertions(+)
> > create mode 100644 drivers/thermal/qoriq_thermal.c
> >
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index
> > 118938e..a200745 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -180,6 +180,17 @@ config IMX_THERMAL
> > cpufreq is used as the cooling device to throttle CPUs when the
> > passive trip is crossed.
> >
> > +config QORIQ_THERMAL
> > + tristate "Freescale QorIQ Thermal Monitoring Unit"
> > + depends on CPU_THERMAL
> > + depends on OF
> > + default n
> > + help
> > + Enable thermal management based on Freescale QorIQ Thermal
> Monitoring
> > + Unit (TMU). It supports one critical trip point and one passive
> trip
> > + point. The cpufreq is used as the cooling device to throttle CPUs
> when
> > + the passive trip is crossed.
> > +
> > config SPEAR_THERMAL
> > bool "SPEAr thermal sensor driver"
> > depends on PLAT_SPEAR
> > diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index
> > 535dfee..8c25859 100644
> > --- a/drivers/thermal/Makefile
> > +++ b/drivers/thermal/Makefile
> > @@ -33,6 +33,7 @@ obj-$(CONFIG_DOVE_THERMAL)+= dove_thermal.o
> > obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
> > obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> > obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
> > +obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
> > obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
> > obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
> > obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
> > diff --git a/drivers/thermal/qoriq_thermal.c
> > b/drivers/thermal/qoriq_thermal.c new file mode 100644 index
> > 000..0694f42
> > --- /dev/null
> > +++ b/drivers/thermal/qoriq_thermal.c
> > @@ -0,0 +1,406 @@
> > +/*
> > + * Copyright 2015 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify it
> > + * under the terms and conditions of the GNU General Public License,
> > + * version 2, as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope it will be useful, but
> > +WITHOUT
> > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> > +or
> > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
> > +License for
> > + * more details.
> > + *
> > + */
> > +
> > +/*
> > + * Based on Freescale QorIQ Thermal Monitoring Unit (TMU) */
> > +#include #include #include
> > + #include #include
> > + #include #include #include
> > + #include
> > +
> > +#define SITES_MAX 16
> > +
> > +#define TMU_TEMP_PASSIVE 85000
> > +#define TMU_TEMP_CRITICAL 95000
> > +
> > +#define TMU_PASSIVE_DELAY 1000/* Milliseconds */
> > +#define TMU_POLLING_DELAY 5000
> > +
> > +/* The driver supports 1 passive trip point and 1 critical trip point
> > +*/ enum tmu_thermal_trip {
> > + TMU_TRIP_PASSIVE,
> > + TMU_TRIP_CRITICAL,
> > + TMU_TRIP_NUM,
> > +};
> > +
> > +/*
> > + * QorIQ TMU Registers
> > + */
> > +struct qoriq_tmu_site_regs {
> > + __be32 tritsr; /* Immediate Temperature Site Register */
> > + __be32 tratsr; /* Average Temperature Site Register */
> > + u8 res0[0x8];
> > +} __packed;
> > +
> > +struct qoriq_tmu_regs {
> > + __be32 tmr;
Re: [PATCH v4 04/46] staging: emxx_udc: add ep capabilities support
On 07/29/2015 05:20 PM, Felipe Balbi wrote:
> On Mon, Jul 27, 2015 at 11:16:14AM +0200, Robert Baldyga wrote:
>> Convert endpoint configuration to new capabilities model.
>>
>> Fixed typo in "epc-nulk" to "epc-bulk".
>>
>> Signed-off-by: Robert Baldyga
>> ---
>> drivers/staging/emxx_udc/emxx_udc.c | 60
>> ++---
>> 1 file changed, 29 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/staging/emxx_udc/emxx_udc.c
>> b/drivers/staging/emxx_udc/emxx_udc.c
>> index 3b7aa36..0d64bee 100644
>> --- a/drivers/staging/emxx_udc/emxx_udc.c
>> +++ b/drivers/staging/emxx_udc/emxx_udc.c
>> @@ -3153,36 +3153,33 @@ static const struct usb_gadget_ops nbu2ss_gadget_ops
>> = {
>> .ioctl = nbu2ss_gad_ioctl,
>> };
>>
>> -static const char g_ep0_name[] = "ep0";
>> -static const char g_ep1_name[] = "ep1-bulk";
>> -static const char g_ep2_name[] = "ep2-bulk";
>> -static const char g_ep3_name[] = "ep3in-int";
>> -static const char g_ep4_name[] = "ep4-iso";
>> -static const char g_ep5_name[] = "ep5-iso";
>> -static const char g_ep6_name[] = "ep6-bulk";
>> -static const char g_ep7_name[] = "ep7-bulk";
>> -static const char g_ep8_name[] = "ep8in-int";
>> -static const char g_ep9_name[] = "ep9-iso";
>> -static const char g_epa_name[] = "epa-iso";
>> -static const char g_epb_name[] = "epb-bulk";
>> -static const char g_epc_name[] = "epc-nulk";
>> -static const char g_epd_name[] = "epdin-int";
>> -
>> -static const char *gp_ep_name[NUM_ENDPOINTS] = {
>> -g_ep0_name,
>> -g_ep1_name,
>> -g_ep2_name,
>> -g_ep3_name,
>> -g_ep4_name,
>> -g_ep5_name,
>> -g_ep6_name,
>> -g_ep7_name,
>> -g_ep8_name,
>> -g_ep9_name,
>> -g_epa_name,
>> -g_epb_name,
>> -g_epc_name,
>> -g_epd_name,
>> +static const struct {
>> +const char *name;
>> +const struct usb_ep_caps caps;
>> +} ep_info[NUM_ENDPOINTS] = {
>> +#define EP_INFO(_name, _type, _dir) \
>> +{ \
>> +.name = _name, \
>> +.caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
>> +USB_EP_CAPS_DIR_ ## _dir), \
>> +}
>> +
>> +EP_INFO("ep0", CONTROL, ALL),
>> +EP_INFO("ep1-bulk", BULK, ALL),
>> +EP_INFO("ep2-bulk", BULK, ALL),
>> +EP_INFO("ep3in-int",INT,IN),
>> +EP_INFO("ep4-iso", INT,ALL),
>> +EP_INFO("ep5-iso", ISO,ALL),
>> +EP_INFO("ep6-bulk", ISO,ALL),
>> +EP_INFO("ep7-bulk", BULK, ALL),
>> +EP_INFO("ep8in-int",INT,IN),
>> +EP_INFO("ep9-iso", ISO,ALL),
>> +EP_INFO("epa-iso", ISO,ALL),
>> +EP_INFO("epb-bulk", BULK, ALL),
>> +EP_INFO("epc-bulk", BULK, ALL),
>> +EP_INFO("epdin-int",INT,IN),
>
> IMO, this is pointless obfuscation. It just makes it a pain to grep
> source around. Why don't you have UDC drivers initialize the 1-bit flags
> directly ?
>
Do you mean something like this? It just makes it a pain to scroll this
source ;)
static const struct {
const char *name;
const struct usb_ep_caps caps;
} ep_info[NUM_ENDPOINTS] = {
{
.name = "ep0",
.caps = {
.type_control = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep1-bulk",
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep2-bulk",
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep3in-int",
.caps = {
.type_int = true,
.dir_in = true,
},
},
{
.name = "ep4-iso",
.caps = {
.type_iso = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep5-iso",
.caps = {
.type_iso = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep6-bulk",
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep7-bulk",
.caps = {
.type_bulk = true,
.dir_in = true,
.dir_out = true,
},
},
{
.name = "ep8in-int",
.caps = {
