Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
On 06/12/2018 15:49:57+, Biju Das wrote:
> Hi Geert,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
> >
> > Hi Biju,
> >
> > On Thu, Dec 6, 2018 at 4:24 PM Biju Das wrote:
> > > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP
> > > > pcf85263 rtc CC nvmem maintainer
> > > >
> > > > On Thu, Dec 6, 2018 at 10:04 AM Biju Das
> > wrote:
> > > > > Add support for NXP pcf85263 real-time clock. pcf85263 rtc is
> > > > > compatible with pcf85363,except that pcf85363 has additional 64
> > > > > bytes of
> > > > RAM.
> >
> > > > > --- a/drivers/rtc/rtc-pcf85363.c
> > > > > +++ b/drivers/rtc/rtc-pcf85363.c
> > > > > @@ -120,6 +120,11 @@ struct pcf85363 {
> > > > > struct regmap *regmap;
> > > > > };
> > > > >
> > > > > +struct pcf85x63_config {
> > > > > + struct regmap_config regmap;
> > > > > + unsigned int num_nvram;
> > > > > +};
> > > > > +
> > > > > static int pcf85363_rtc_read_time(struct device *dev, struct
> > > > > rtc_time
> > > > > *tm) {
> > > > > struct pcf85363 *pcf85363 = dev_get_drvdata(dev); @@
> > > > > -311,25
> > > > > +316,68 @@ static int pcf85363_nvram_write(void *priv, unsigned
> > > > > +int
> > > > offset, void *val,
> > > > > val, bytes); }
> > > > >
> > > > > -static const struct regmap_config regmap_config = {
> > > > > - .reg_bits = 8,
> > > > > - .val_bits = 8,
> > > > > - .max_register = 0x7f,
> > > > > +static int pcf85x63_nvram_read(void *priv, unsigned int offset, void
> > *val,
> > > > > + size_t bytes)
> > > >
> > > > Given bytes should be 1, val should be a pointer to a single byte...
> > > > What if bytes == 0?
> > >
> > > I doubt we get "bytes==0" because of the checks in "
> > drivers/nvmem/core.c"
> > > Function " bin_attr_nvmem_read/ bin_attr_nvmem_write".
> >
> > Depends. There are other functions calling nvmem_reg_{read,write}(), e.g.
> > nvmem_device_{read,write}().
>
> OK. In that case, I will return (-EINVAL) for "bytes !=1"
>
I think it is probably better to ensure the nvmem core never passes an
invalid number of bytes. All the ther RTC drivers make that assumption.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v2 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
On 30/11/2018 12:05:16+0100, Geert Uytterhoeven wrote:
> Hi Biju,
>
> On Thu, Nov 29, 2018 at 6:03 PM Biju Das wrote:
> > Add support for NXP pcf85263 real-time clock. pcf85263 rtc is compatible
> > with pcf85363,except that pcf85363 has additional 64 bytes of RAM.
> >
> > 1 byte of nvmem is supported and exposed in sysfs (# is the instance
> > number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem
> >
> > Signed-off-by: Biju Das
> > ---
> > V1-->V2 Incorporated Alexandre and Geert's review comment.
>
> Thanks for the update!
>
> > --- a/drivers/rtc/rtc-pcf85363.c
> > +++ b/drivers/rtc/rtc-pcf85363.c
>
> > @@ -321,15 +344,25 @@ static int pcf85363_probe(struct i2c_client *client,
> > const struct i2c_device_id *id)
> > {
> > struct pcf85363 *pcf85363;
> > - struct nvmem_config nvmem_cfg = {
> > - .name = "pcf85363-",
> > - .word_size = 1,
> > - .stride = 1,
> > - .size = NVRAM_SIZE,
> > - .reg_read = pcf85363_nvram_read,
> > - .reg_write = pcf85363_nvram_write,
> > + const struct regmap_config *regmap_config =
> > _85363_regmap_config;
> > + struct nvmem_config nvmem_cfg[] = {
>
> static?
>
> Although the nvmem_config is copied, and thus static is not needed, I
> guess using static will decrease kernel size.
>
Hum, I don't think, this is on the stack anyway.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
On 21/11/2018 11:23:08+0100, Geert Uytterhoeven wrote:
> Hi Biju,
>
> On Mon, Nov 19, 2018 at 12:23 PM Biju Das wrote:
> > Add support for NXP pcf85263 real-time clock. pcf85263 rtc is compatible
> > with pcf85363,except that pcf85363 has additional 64 bytes of RAM.
> >
> > 1 byte of nvmem is supported and exposed in sysfs (# is the instance
> > number,starting with 0): /sys/bus/nvmem/devices/pcf85263-#/nvmem
> >
> > Signed-off-by: Biju Das
>
> Thanks for your patch!
>
> > --- a/drivers/rtc/rtc-pcf85363.c
> > +++ b/drivers/rtc/rtc-pcf85363.c
> > @@ -311,7 +311,30 @@ static int pcf85363_nvram_write(void *priv, unsigned
> > int offset, void *val,
> > val, bytes);
> > }
> >
> > -static const struct regmap_config regmap_config = {
> > +static int pcf85263_nvram_read(void *priv, unsigned int offset, void *val,
> > + size_t bytes)
> > +{
> > + struct pcf85363 *pcf85363 = priv;
> > +
> > + return regmap_read(pcf85363->regmap, CTRL_RAMBYTE, val);
> > +}
>
> AFAIU without reading the datasheet, the pcf85363 also has this RAMBYTE
> register. Would it make sense to expose the contents on both parts?
>
Yes it has. This series allows calling rtc_nvmem_register() multiple
times from the same driver:
http://patchwork.ozlabs.org/project/rtc-linux/list/?series=75212
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 44/61] rtc: simplify getting .drvdata
On 19/04/2018 16:06:14+0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > --- > > Build tested only. buildbot is happy. Please apply individually. > > drivers/rtc/rtc-bq4802.c | 6 ++ > drivers/rtc/rtc-ds1216.c | 6 ++ > drivers/rtc/rtc-ds1511.c | 9 +++-- > drivers/rtc/rtc-ds1553.c | 15 +-- > drivers/rtc/rtc-ds1685.c | 21 +++-- > drivers/rtc/rtc-ds1742.c | 6 ++ > drivers/rtc/rtc-lpc32xx.c | 16 ++-- > drivers/rtc/rtc-m48t59.c | 41 - > drivers/rtc/rtc-mv.c | 3 +-- > drivers/rtc/rtc-mxc.c | 21 +++-- > drivers/rtc/rtc-pcap.c | 15 +-- > drivers/rtc/rtc-sh.c | 15 +-- > drivers/rtc/rtc-stk17ta8.c | 15 +-- > drivers/rtc/rtc-test.c | 3 +-- > drivers/rtc/rtc-zynqmp.c | 10 -- > 15 files changed, 71 insertions(+), 131 deletions(-) > Applied, thanks. -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses
Hi,
On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
> > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> > > It's been a while since we introduced drm_dev{get/put} functions
> > > to replace reference/unreference in drm subsystem for the
> > > consistency purpose. So, with this patch, let's just replace
> > > all current use cases of drm_dev_unref() with drm_dev_put and remove
> > > the function itself.
> > >
> > > Coccinelle was used for mass-patching.
> > >
> > > Signed-off-by: Vaishali Thakkar <vthakkar1...@gmail.com>
> >
> > Thanks for doing this. Unfortunately drm moves pretty fast, so already a
> > conflict when I tried to apply this. Some drivers are also in their own
> > trees, so this might lead to more fun :-/
> >
> > Can you pls split it up per-driver (just the directories under
> > drivers/gpu/drm/ is enough)? Final patch to remove the function might then
> > get stalled a bit ofc.
>
> I requested a single patch instead of splitting it per driver, you might want
> to blame me for that.
>
Doesn't splitting the change per driver break bisectability unless there
is a guarantee that the change in include/drm/drm_drv.h is applied after
all the driver trees have been merged?
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 3/8] media: v4l2-async: simplify v4l2_async_subdev structure
On 18/12/2017 at 17:53:57 -0200, Mauro Carvalho Chehab wrote:
> The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> match criteria requires just a device name.
>
> So, it doesn't make sense to enclose those into structs,
> as the criteria can go directly into the union.
>
> That makes easier to document it, as we don't need to document
> weird senseless structs.
>
> At drivers, this makes even clearer about the match criteria.
>
For atmel:
Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
> Acked-by: Sylwester Nawrocki <s.nawro...@samsung.com>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
> drivers/media/platform/am437x/am437x-vpfe.c| 6 +++---
> drivers/media/platform/atmel/atmel-isc.c | 2 +-
> drivers/media/platform/atmel/atmel-isi.c | 2 +-
> drivers/media/platform/davinci/vpif_capture.c | 4 ++--
> drivers/media/platform/exynos4-is/media-dev.c | 4 ++--
> drivers/media/platform/pxa_camera.c| 2 +-
> drivers/media/platform/qcom/camss-8x16/camss.c | 2 +-
> drivers/media/platform/rcar-vin/rcar-core.c| 2 +-
> drivers/media/platform/rcar_drif.c | 4 ++--
> drivers/media/platform/soc_camera/soc_camera.c | 2 +-
> drivers/media/platform/stm32/stm32-dcmi.c | 2 +-
> drivers/media/platform/ti-vpe/cal.c| 2 +-
> drivers/media/platform/xilinx/xilinx-vipp.c| 2 +-
> drivers/media/v4l2-core/v4l2-async.c | 16
> drivers/media/v4l2-core/v4l2-fwnode.c | 10 +-
> drivers/staging/media/imx/imx-media-dev.c | 4 ++--
> include/media/v4l2-async.h | 8 ++--
> 17 files changed, 35 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index 0997c640191d..601ae6487617 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -2304,8 +2304,8 @@ vpfe_async_bound(struct v4l2_async_notifier *notifier,
> vpfe_dbg(1, vpfe, "vpfe_async_bound\n");
>
> for (i = 0; i < ARRAY_SIZE(vpfe->cfg->asd); i++) {
> - if (vpfe->cfg->asd[i]->match.fwnode.fwnode ==
> - asd[i].match.fwnode.fwnode) {
> + if (vpfe->cfg->asd[i]->match.fwnode ==
> + asd[i].match.fwnode) {
> sdinfo = >cfg->sub_devs[i];
> vpfe->sd[i] = subdev;
> vpfe->sd[i]->grp_id = sdinfo->grp_id;
> @@ -2510,7 +2510,7 @@ vpfe_get_pdata(struct platform_device *pdev)
> }
>
> pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
> + pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
> of_node_put(rem);
> }
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c
> b/drivers/media/platform/atmel/atmel-isc.c
> index 0c2635647f69..34676409ca08 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -2088,7 +2088,7 @@ static int isc_parse_dt(struct device *dev, struct
> isc_device *isc)
> subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
>
> subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - subdev_entity->asd->match.fwnode.fwnode =
> + subdev_entity->asd->match.fwnode =
> of_fwnode_handle(rem);
> list_add_tail(_entity->list, >subdev_entities);
> }
> diff --git a/drivers/media/platform/atmel/atmel-isi.c
> b/drivers/media/platform/atmel/atmel-isi.c
> index e900995143a3..9958918e2449 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -1128,7 +1128,7 @@ static int isi_graph_parse(struct atmel_isi *isi,
> struct device_node *node)
> /* Remote node to connect */
> isi->entity.node = remote;
> isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - isi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
> + isi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> return 0;
> }
> }
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c
> index e45916f69def..e1c273c8b9a6 100644
> --- a/drivers/media/platform/da
Re: [PATCH v3 0/7] rtc: Reuse rtc-sh driver to support RZ/A1
Hi, On 29/03/2017 at 10:30:28 -0700, Chris Brandt wrote: > Basically, the same RTC that was used in SuperH devices is now used in > RZ/A1 devices. Therefore with some slight changes, that driver can be > reused. > > Additionally, since ARM architectures require Device Tree configurations, > device tree support has been added. > > This was tested on RZ/A1H RSK board. Once the correct time was programmed > into the RTC running off a 32.768kHz crystal, you can retain an accurate > system clock between reboots (hard and soft) until power is finally removed > from the board (there is no batter backup on the RSK board). > > v3: > * remove 'power-domains' from example in documentation > * update commit message subject and body of dt-bindings > > v2: > * removed HAVE_CLK from Kconfig > * when using DT, look for "fck" instead of "rtc0" > * changed (res == NULL) to (!res) > * added Reviewed-by for rtc-sh.c > * added interrupt-names and clock-names > * clocks now include counting sources > * added clock-names "fck", "rtc_x1", "rtc_x3", "extal" > * changed 'is a RTC' to 'is an RTC' in commit message > * changed "rtc0" to "rtc" > * Added clock nodes for RTC_X1 and RTC_X3 pin inputs > * each commit now has a log message > > > Chris Brandt (7): > rtc: rtc-sh: add support for rza series > dt-bindings: rtc: document the rtc-sh bindings I applied those two, I'll let Simon take the device tree patches. Thanks! > ARM: dts: r7s72100: add rtc clock to device tree > ARM: dts: r7s72100: add RTC_X clock inputs to device tree > ARM: dts: r7s72100: add rtc to device tree > ARM: dts: rskrza1: set rtc_x1 clock value > ARM: dts: rskrza1: add rtc DT support -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH 2/5] rtc: Add rtc-sh
On 20/03/2017 at 16:26:46 +, Chris Brandt wrote:
> Hi Geert,
>
> On Monday, March 20, 2017, Geert Uytterhoeven wrote:
> > > + rtc: rtc@fcff1000 {
> > > + compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
> > > + reg = <0xfcff1000 0x2e>;
> > > + interrupts = > > + GIC_SPI 277 IRQ_TYPE_EDGE_RISING
> > > + GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
> > > + interrupt-names = "alarm", "period", "carry";
> > > + clocks = <_clks R7S72100_CLK_RTC>, <_x1_clk>,
> > > + <_clk> , <_x3_clk>;
> > > + clock-names = "fck", "rtc_x1", "extal", "rtc_x3";
> > > + power-domains = <_clocks>;
> > > + count-source = "rtc_x1";<<<<<<< this would be in the
> > board dts file
> >
> > IMHO that's software policy, not hardware description, so it doesn't
> > belong in DT.
>
> Really? I'm so confused about what is and isn't the responsibility of DT.
>
>
> > However, by scanning the list of allowed clock names, and looking at clock
> > rates, the driver can find a suitable clock itself.
>
> Yes, I could make the selection automatic by looking that the clock names (and
> I will do that for this driver), but what about the case where a user needs
> to select something from a list of possible HW options? In other words, where
> does 'software option' selection stuff go if not in the DT?
>
If you want you can leave the clock selection logic out of the driver as
long as the DT binding is complete. You dont have to use everything that
is described in the DT.
Regarding the selection, I'd say take the first that is present and not
0 however, if something has already been set, you may not want to
override it. (I know, this is not helping a lot ;) )
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [PATCH 1/5] rtc: rtc-sh: add support for rza series
Mostly good, one nitpick: On 16/03/2017 at 13:51:08 -0400, Chris Brandt wrote: > res = platform_get_resource(pdev, IORESOURCE_IO, 0); > + if (res == NULL) if (!res) is preferred here -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH 2/5] rtc: Add rtc-sh
Hi, On 17/03/2017 at 14:55:48 +0100, Geert Uytterhoeven wrote: > >> it would still be good to have phandles to the external clock sources as > >> well, as that describes the hardware topology. > > > > I'm confused, you mean make new clocks node for RTC_X1 (fixed at 32.768kHZ) > > and > > RTC_X3 (fixed at 4MHz), but then not really do anything with then? (the > > driver > > You still do something with them, as they'll be linked from the rtc device > node. > > > doesn't need them) > > The driver may use them in the future. > E.g. to select among X1, X3, or EXTAL, depending on availability. > I'm on Geert's side here, I wouldn't rely on the bootloader to set everything up correctly. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [RFT PATCH v2 2/3] ARM: Fix *MIGHT_HAVE_PCI* config from being selected redundantly
On 01/08/2016 at 17:50:07 +0200, Nicolas Ferre wrote : > Le 01/08/2016 13:12, Kishon Vijay Abraham I a écrit : > > *MIGHT_HAVE_PCI* config is already selected in ARCH_MULTIPLATFORM. > > Fix it from getting redundantly selected in all > > ARCH_MULTIPLATFORM based machines. > > And what happens if we select just one platform independently? > That is fine for us because SOC_AT91RM9200 can only be selected once ARCH_MULTIPLATFORM is selected anyway. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [RFT PATCH v2 2/3] ARM: Fix *MIGHT_HAVE_PCI* config from being selected redundantly
On 01/08/2016 at 16:42:29 +0530, Kishon Vijay Abraham I wrote : > *MIGHT_HAVE_PCI* config is already selected in ARCH_MULTIPLATFORM. > Fix it from getting redundantly selected in all > ARCH_MULTIPLATFORM based machines. > For mach-at91: Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> > Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com> > --- > arch/arm/Kconfig |2 -- > arch/arm/mach-at91/Kconfig |1 - > arch/arm/mach-axxia/Kconfig |1 - > arch/arm/mach-exynos/Kconfig |1 - > arch/arm/mach-integrator/Kconfig |1 - > arch/arm/mach-keystone/Kconfig |1 - > arch/arm/mach-ks8695/Kconfig |5 - > arch/arm/mach-pxa/Kconfig|1 - > arch/arm/mach-spear/Kconfig |1 - > arch/arm/mach-versatile/Kconfig |1 - > 10 files changed, 15 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 90542db..538b032 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -474,7 +474,6 @@ config ARCH_IXP4XX > select CPU_XSCALE > select DMABOUNCE if PCI > select GENERIC_CLOCKEVENTS > - select MIGHT_HAVE_PCI > select NEED_MACH_IO_H > select USB_EHCI_BIG_ENDIAN_DESC > select USB_EHCI_BIG_ENDIAN_MMIO > @@ -486,7 +485,6 @@ config ARCH_DOVE > select ARCH_REQUIRE_GPIOLIB > select CPU_PJ4 > select GENERIC_CLOCKEVENTS > - select MIGHT_HAVE_PCI > select MULTI_IRQ_HANDLER > select MVEBU_MBUS > select PINCTRL > diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig > index 08047af..4013427 100644 > --- a/arch/arm/mach-at91/Kconfig > +++ b/arch/arm/mach-at91/Kconfig > @@ -55,7 +55,6 @@ config SOC_AT91RM9200 > select ATMEL_ST > select CPU_ARM920T > select HAVE_AT91_USB_CLK > - select MIGHT_HAVE_PCI > select PINCTRL_AT91 > select SOC_SAM_V4_V5 > select SRAM if PM > diff --git a/arch/arm/mach-axxia/Kconfig b/arch/arm/mach-axxia/Kconfig > index 6c6d5e7..ee2e131 100644 > --- a/arch/arm/mach-axxia/Kconfig > +++ b/arch/arm/mach-axxia/Kconfig > @@ -7,7 +7,6 @@ config ARCH_AXXIA > select ARM_TIMER_SP804 > select HAVE_ARM_ARCH_TIMER > select MFD_SYSCON > - select MIGHT_HAVE_PCI > select PCI_DOMAINS if PCI > select ZONE_DMA > help > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig > index 20dcf6e..a03daf5 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -125,7 +125,6 @@ config SOC_EXYNOS5440 > select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE > select HAVE_ARM_ARCH_TIMER > select AUTO_ZRELADDR > - select MIGHT_HAVE_PCI > select PCI_DOMAINS if PCI > select PINCTRL_EXYNOS5440 > select PM_OPP > diff --git a/arch/arm/mach-integrator/Kconfig > b/arch/arm/mach-integrator/Kconfig > index b2a85ba..4ed202c 100644 > --- a/arch/arm/mach-integrator/Kconfig > +++ b/arch/arm/mach-integrator/Kconfig > @@ -21,7 +21,6 @@ if ARCH_INTEGRATOR > config ARCH_INTEGRATOR_AP > bool "Support Integrator/AP and Integrator/PP2 platforms" > select CLKSRC_MMIO > - select MIGHT_HAVE_PCI > select SERIAL_AMBA_PL010 if TTY > select SERIAL_AMBA_PL010_CONSOLE if TTY > select SOC_BUS > diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig > index ea955f6db..6bd14da 100644 > --- a/arch/arm/mach-keystone/Kconfig > +++ b/arch/arm/mach-keystone/Kconfig > @@ -9,7 +9,6 @@ config ARCH_KEYSTONE > select COMMON_CLK_KEYSTONE > select ARCH_SUPPORTS_BIG_ENDIAN > select ZONE_DMA if ARM_LPAE > - select MIGHT_HAVE_PCI > select PCI_DOMAINS if PCI > help > Support for boards based on the Texas Instruments Keystone family of > diff --git a/arch/arm/mach-ks8695/Kconfig b/arch/arm/mach-ks8695/Kconfig > index a545976..4ef06bc 100644 > --- a/arch/arm/mach-ks8695/Kconfig > +++ b/arch/arm/mach-ks8695/Kconfig > @@ -4,7 +4,6 @@ menu "Kendin/Micrel KS8695 Implementations" > > config MACH_KS8695 > bool "KS8695 development board" > - select MIGHT_HAVE_PCI > help > Say 'Y' here if you want your kernel to run on the original > Kendin-Micrel KS8695 development board. > @@ -52,7 +51,6 @@ config MACH_CM4002 > > config MACH_CM4008 > bool "OpenGear CM4008" > - select MIGHT_HAVE_PCI > help > Say 'Y' here if you want your kernel to support the OpenGear > CM4008 Console Server. See http://www.opengear.com for more > @@ -60,7 +58,6 @@ config MACH_CM4008 >
