* RE: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
From: Fabrizio Castro @ 2017-12-19 10:17 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Simon Horman, Geert Uytterhoeven, linux-can@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Chris Paterson, Biju Das,
Fabrizio Castro, Wolfgang Grandegger, Rob Herring, Mark Rutland
In-Reply-To: <1510067449-17017-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hello Marc,
does this patch look ok to you?
Thanks,
Fab
> Subject: [PATCH 1/8] dt-bindings: can: rcar_can: document r8a774[35] can support
>
> Document "renesas,can-r8a7743" and "renesas,can-r8a7745" compatible
> strings. Since the fallback compatible string ("renesas,rcar-gen2-can")
> activates the right code in the driver, no driver change is needed.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/net/can/rcar_can.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 06bb7cc..94a7f33 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -2,7 +2,9 @@ Renesas R-Car CAN controller Device Tree Bindings
> -------------------------------------------------
>
> Required properties:
> -- compatible: "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> +- compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
> + "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
> + "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
> "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
> "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC.
> @@ -12,7 +14,8 @@ Required properties:
> "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
> "renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
> "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
> - "renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device.
> + "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
> + compatible device.
> "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
> When compatible with the generic version, nodes must list the
> SoC-specific version corresponding to the platform first
> --
> 2.7.4
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH v4 25/36] nds32: Miscellaneous header files
From: Arnd Bergmann @ 2017-12-19 9:54 UTC (permalink / raw)
To: Greentime Hu
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAEbi=3fWvrvdqUYOWdmbAHDmMpLiUaTaL_-jUjqg=p4aZiMLrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Dec 19, 2017 at 6:34 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi, Arnd:
>
> 2017-12-18 19:13 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>> On Mon, Dec 18, 2017 at 7:46 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>>
>>> This patch introduces some miscellaneous header files.
>>
>>> +static inline void __delay(unsigned long loops)
>>> +{
>>> + __asm__ __volatile__(".align 2\n"
>>> + "1:\n"
>>> + "\taddi\t%0, %0, -1\n"
>>> + "\tbgtz\t%0, 1b\n"
>>> + :"=r"(loops)
>>> + :"0"(loops));
>>> +}
>>> +
>>> +static inline void __udelay(unsigned long usecs, unsigned long lpj)
>>> +{
>>> + usecs *= (unsigned long)(((0x8000000000000000ULL / (500000 / HZ)) +
>>> + 0x80000000ULL) >> 32);
>>> + usecs = (unsigned long)(((unsigned long long)usecs * lpj) >> 32);
>>> + __delay(usecs);
>>> +}
>>
>> Do you have a reliable clocksource that you can read here instead of doing the
>> loop? It's generally preferred to have an accurate delay if at all possible, the
>> delay loop calibration is only for those architectures that don't have any
>> way to observe how much time has passed accurately.
>>
>
> We currently only have atcpit100 as clocksource but it is an IP of SoC.
> These delay API will be unavailable if we changed to another SoC
> unless all these timer driver provided the same APIs.
> It may suffer our customers if they forget to port these APIs in their
> timer drivers when they try to use nds32 in the first beginning.
Ok, thanks for the clarification.
> Or maybe I can use a CONFIG_USE_ACCURATE_DELAY to keep these 2
> implementions for these purposes?
I'd just add a one-line comment in delay.h to explain that there is no
cycle counter in the CPU.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] phy: ti-pipe3: configure usb3 phy to be used as pcie phy
From: Kishon Vijay Abraham I @ 2017-12-19 9:45 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, kishon
Cc: devicetree, linux-pci, linux-kernel, nsekhar
In-Reply-To: <20171219094540.18432-1-kishon@ti.com>
DRA72 uses USB3 PHY for the 2nd lane of PCIE. The configuration
required to make USB3 PHY used for the 2nd lane of PCIe is done
here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
drivers/phy/ti/phy-ti-pipe3.c | 47 +++++++++++++++++++++++++++++++++++++------
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index 68ce4a082b9b..d5a7cc435fb7 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -56,6 +56,12 @@
#define SATA_PLL_SOFT_RESET BIT(18)
+#define PHY_RX_ANA_PRGRAMMABILITY_REG 0xC
+#define MEM_EN_PLLBYP BIT(7)
+
+#define PHY_TX_TEST_CONFIG 0x2C
+#define MEM_ENTESTCLK BIT(31)
+
#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
@@ -110,6 +116,10 @@
#define PLL_IDLE_TIME 100 /* in milliseconds */
#define PLL_LOCK_TIME 100 /* in milliseconds */
+#define PIPE3_PHY_DISABLE_SYNC_POWER BIT(4)
+
+#define CONFIGURE_AS_PCIE BIT(0)
+
struct pipe3_dpll_params {
u16 m;
u8 n;
@@ -141,6 +151,7 @@ struct ti_pipe3 {
unsigned int power_reg; /* power reg. index within syscon */
unsigned int pcie_pcs_reg; /* pcs reg. index in syscon */
bool sata_refclk_enabled;
+ u32 flags;
};
static struct pipe3_dpll_map dpll_map_usb[] = {
@@ -233,11 +244,22 @@ static int ti_pipe3_power_on(struct phy *x)
rate = rate / 1000000;
mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
- val = PIPE3_PHY_TX_RX_POWERON << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+ val = PIPE3_PHY_TX_RX_POWERON;
+ if (phy->flags & CONFIGURE_AS_PCIE)
+ val |= PIPE3_PHY_DISABLE_SYNC_POWER;
+ val <<= PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
val |= rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
mask, val);
+
+ if (phy->flags & CONFIGURE_AS_PCIE) {
+ ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+ mask, val);
+ if (ret < 0)
+ return ret;
+ }
+
return ret;
}
@@ -335,6 +357,19 @@ static int ti_pipe3_init(struct phy *x)
int ret = 0;
ti_pipe3_enable_clocks(phy);
+
+ if (phy->flags & CONFIGURE_AS_PCIE) {
+ val = ti_pipe3_readl(phy->phy_rx,
+ PHY_RX_ANA_PRGRAMMABILITY_REG);
+ val |= MEM_EN_PLLBYP;
+ ti_pipe3_writel(phy->phy_rx, PHY_RX_ANA_PRGRAMMABILITY_REG,
+ val);
+ val = ti_pipe3_readl(phy->phy_tx, PHY_TX_TEST_CONFIG);
+ val |= MEM_ENTESTCLK;
+ ti_pipe3_writel(phy->phy_tx, PHY_TX_TEST_CONFIG, val);
+ return 0;
+ }
+
/*
* Set pcie_pcs register to 0x96 for proper functioning of phy
* as recommended in AM572x TRM SPRUHZ6, section 18.5.2.2, table
@@ -395,7 +430,8 @@ static int ti_pipe3_exit(struct phy *x)
return 0;
/* PCIe doesn't have internal DPLL */
- if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
+ if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie") &&
+ !(phy->flags & CONFIGURE_AS_PCIE)) {
/* Put DPLL in IDLE mode */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
val |= PLL_IDLE;
@@ -589,12 +625,8 @@ static int ti_pipe3_get_tx_rx_base(struct ti_pipe3 *phy)
{
struct resource *res;
struct device *dev = phy->dev;
- struct device_node *node = dev->of_node;
struct platform_device *pdev = to_platform_device(dev);
- if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie"))
- return 0;
-
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"phy_rx");
phy->phy_rx = devm_ioremap_resource(dev, res);
@@ -666,6 +698,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
+ if (of_property_read_bool(node, "ti,configure-as-pcie"))
+ phy->flags |= CONFIGURE_AS_PCIE;
+
platform_set_drvdata(pdev, phy);
pm_runtime_enable(dev);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: phy: ti-pipe3: Add dt binding to use USB3 PHY for PCIe
From: Kishon Vijay Abraham I @ 2017-12-19 9:45 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, kishon
Cc: devicetree, linux-pci, linux-kernel, nsekhar
In-Reply-To: <20171219094540.18432-1-kishon@ti.com>
DRA72 uses USB3 PHY for the 2nd lane of PCIE. Add dt bindings property
to indicate if the USB3 PHY should be used for 2nd lane of PCIe.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
Documentation/devicetree/bindings/phy/ti-phy.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
index cd13e6157088..907a046e794b 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -93,6 +93,8 @@ Optional properties:
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
- syscon-pcs : phandle/offset pair. Phandle to the system control module and the
register offset to write the PCS delay value.
+ - "ti,configure-as-pcie" : property to indicate if the PHY should be
+ configured as PCIE PHY.
Deprecated properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] ti-pipe3: PCIe x2 lane mode configuration in dra72
From: Kishon Vijay Abraham I @ 2017-12-19 9:45 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, kishon-l0cyMroinI0
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0
DRA72 uses the same pipe3 PHY for the 2nd lane of PCIE and USB3 PHY.
By default it is configured to be used as USB3 PHY and some special
configuration has to be done inorder to use it for the 2nd lane of PCIE.
This series adds a new dt property and the configuration required to
enable 2nd lane of PCIE.
Kishon Vijay Abraham I (2):
dt-bindings: phy: ti-pipe3: Add dt binding to use USB3 PHY for PCIe
phy: ti-pipe3: configure usb3 phy to be used as pcie phy
Documentation/devicetree/bindings/phy/ti-phy.txt | 2 +
drivers/phy/ti/phy-ti-pipe3.c | 47 +++++++++++++++++++++---
2 files changed, 43 insertions(+), 6 deletions(-)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
From: Greg Kroah-Hartman @ 2017-12-19 9:36 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni, Nishanth Menon,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree
In-Reply-To: <20171219102858.001d4bf5@bbrezillon>
On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote:
> On Tue, 19 Dec 2017 10:21:19 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> > > On Tue, 19 Dec 2017 10:09:00 +0100
> > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> > >
> > > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > > > > > +/**
> > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > > + * @id_table: the I3C device ID table
> > > > > > + *
> > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > > > > + * no match.
> > > > > > + */
> > > > > > +const struct i3c_device_id *
> > > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > > + const struct i3c_device_id *id_table)
> > > > > > +{
> > > > > > + const struct i3c_device_id *id;
> > > > > > +
> > > > > > + /*
> > > > > > + * The lower 32bits of the provisional ID is just filled with a random
> > > > > > + * value, try to match using DCR info.
> > > > > > + */
> > > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > > +
> > > > > > + /* First try to match by manufacturer/part ID. */
> > > > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > > > > + I3C_MATCH_MANUF_AND_PART)
> > > > > > + continue;
> > > > > > +
> > > > > > + if (manuf != id->manuf_id || part != id->part_id)
> > > > > > + continue;
> > > > > > +
> > > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > > + ext_info != id->extra_info)
> > > > > > + continue;
> > > > > > +
> > > > > > + return id;
> > > > > > + }
> > > > > > + }
> > > > > > +
> > > > > > + /* Fallback to DCR match. */
> > > > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > > > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > > + id->dcr == i3cdev->info.dcr)
> > > > > > + return id;
> > > > > > + }
> > > > > > +
> > > > > > + return NULL;
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
> > > > >
> > > > > I just picked one random export here, but it feels like you are
> > > > > exporting a bunch of symbols you don't need to. Why would something
> > > > > outside of the i3c "core" need to call this function?
> > > >
> > > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > > if the driver is supporting different variants of the device, it may
> > > > want to know which one is being probed.
> > > >
> > > > I considered retrieving this information in the core just before probing
> > > > the driver and passing it to the ->probe() function, but it means
> > > > having an extra i3c_device_match_id() call for everyone even those who
> > > > don't care about the device_id information, so I thought exporting this
> > > > function was a good alternative (device drivers can use it when they
> > > > actually need to retrieve the device_id).
> > > >
> > > > Anyway, that's something I can change if you think passing the
> > > > i3c_device_id to the ->probe() method is preferable.
> > > >
> > > > > Have you looked
> > > > > to see if you really have callers for everything you are exporting?
> > > >
> > > > Yes, I tried to only export functions that I think will be needed by
> > > > I3C device drivers and I3C master drivers. Note that I didn't post the
> > > > dummy device driver I developed to test the framework (partly because
> > > > this is
> > >
> > > Sorry, I hit the send button before finishing my sentence :-).
> > >
> > > "
> > > Note that I didn't post the dummy device driver [1] I developed to test
> > > the framework (partly because the quality of the code does not meet
> > > mainline standards and I was ashamed of posting it publicly :-)), but
> > > this driver is using some of the exported functions.
> > > "
> >
> > We don't export functions that has no in-kernel users :)
>
> But then, I can't export device driver related functions, because
> there's no official device driver yet :-). So what should I do?
Export them when you have a driver. Or better yet, submit a driver as
part of the patch series. Why would we want infrastructure that no one
uses?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 7/7] ARM: multi_v7_defconfig: Enable CONFIG_PCI_DRA7XX (Host & Device modes)
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: Tony Lindgren, bcousson-rdvid1DuHRBWk0Htik3J/w
Cc: Rob Herring, Mark Rutland, Russell King,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nsekhar-l0cyMroinI0, kishon-l0cyMroinI0
In-Reply-To: <20171219093133.16565-1-kishon-l0cyMroinI0@public.gmane.org>
Enable CONFIG_PCI_DRA7XX in order to be able to configure PCIe
controller present in dra7 SoCs in both host mode and device mode.
Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
---
arch/arm/configs/multi_v7_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 61509c4b769f..6faecd55ccbd 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -116,6 +116,8 @@ CONFIG_ARCH_ZYNQ=y
CONFIG_TRUSTED_FOUNDATIONS=y
CONFIG_PCI=y
CONFIG_PCI_HOST_GENERIC=y
+CONFIG_PCI_DRA7XX=y
+CONFIG_PCI_DRA7XX_EP=y
CONFIG_PCI_KEYSTONE=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MVEBU=y
@@ -123,6 +125,9 @@ CONFIG_PCI_TEGRA=y
CONFIG_PCI_RCAR_GEN2=y
CONFIG_PCIE_RCAR=y
CONFIG_PCIEPORTBUS=y
+CONFIG_PCI_ENDPOINT=y
+CONFIG_PCI_ENDPOINT_CONFIGFS=y
+CONFIG_PCI_EPF_TEST=m
CONFIG_SMP=y
CONFIG_NR_CPUS=16
CONFIG_HIGHPTE=y
@@ -222,6 +227,7 @@ CONFIG_ATMEL_SSC=m
CONFIG_QCOM_COINCELL=m
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
+CONFIG_PCI_ENDPOINT_TEST=m
CONFIG_EEPROM_AT24=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 6/7] ARM: omap2plus_defconfig: Enable CONFIG_PCI_DRA7XX (Host & Device modes)
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: Tony Lindgren, bcousson
Cc: Rob Herring, Mark Rutland, Russell King, linux-pci, devicetree,
linux-kernel, linux-omap, linux-arm-kernel, nsekhar, kishon
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
Enable CONFIG_PCI_DRA7XX in order to be able to configure PCIe
controller present in dra7 SoCs in both host mode and device mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 7b97200c1d64..a01871d5aa73 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -48,6 +48,13 @@ CONFIG_SOC_AM43XX=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_ERRATA_411920=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_DRA7XX=y
+CONFIG_PCI_DRA7XX_EP=y
+CONFIG_PCI_ENDPOINT=y
+CONFIG_PCI_ENDPOINT_CONFIGFS=y
+CONFIG_PCI_EPF_TEST=m
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_CMA=y
@@ -137,6 +144,7 @@ CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_SENSORS_TSL2550=m
CONFIG_SRAM=y
+CONFIG_PCI_ENDPOINT_TEST=m
CONFIG_EEPROM_AT24=m
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_SCAN_ASYNC=y
--
2.11.0
^ permalink raw reply related
* [PATCH 5/7] ARM: dts: dra7: Remove deprecated PCI compatible string
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: Tony Lindgren, bcousson
Cc: Rob Herring, Mark Rutland, Russell King, linux-pci, devicetree,
linux-kernel, linux-omap, linux-arm-kernel, nsekhar, kishon
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
Since SoC specific compatible strings are used for PCIe in
dra74x.dtsi and dra72x.dtsi, remove the compatible property
from dra7.dtsi which uses the deprecated compatible string.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 333f6a634ff9..1efa908c7bce 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -293,7 +293,6 @@
* node and enable pcie1_ep mode.
*/
pcie1_rc: pcie@51000000 {
- compatible = "ti,dra7-pcie";
reg = <0x51000000 0x2000>, <0x51002000 0x14c>, <0x1000 0x2000>;
reg-names = "rc_dbics", "ti_conf", "config";
interrupts = <0 232 0x4>, <0 233 0x4>;
@@ -325,7 +324,6 @@
};
pcie1_ep: pcie_ep@51000000 {
- compatible = "ti,dra7-pcie-ep";
reg = <0x51000000 0x28>, <0x51002000 0x14c>, <0x51001000 0x28>, <0x1000 0x10000000>;
reg-names = "ep_dbics", "ti_conf", "ep_dbics2", "addr_space";
interrupts = <0 232 0x4>;
@@ -350,7 +348,6 @@
0x0 0x30000000 0x10000000>;
status = "disabled";
pcie2_rc: pcie@51800000 {
- compatible = "ti,dra7-pcie";
reg = <0x51800000 0x2000>, <0x51802000 0x14c>, <0x1000 0x2000>;
reg-names = "rc_dbics", "ti_conf", "config";
interrupts = <0 355 0x4>, <0 356 0x4>;
--
2.11.0
^ permalink raw reply related
* [PATCH 4/7] ARM: dts: dra76-evm: Enable x2 PCIe lanes
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: Tony Lindgren, bcousson
Cc: Rob Herring, Mark Rutland, Russell King, linux-pci, devicetree,
linux-kernel, linux-omap, linux-arm-kernel, nsekhar, kishon
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
DRA76 EVM has a 4-lane PCIe connector and DRA76 can support x2 lanes.
Enable both the PCIe lanes here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra76-evm.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index b024a65c6e27..244e553f2247 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -421,3 +421,19 @@
spi-max-frequency = <96000000>;
};
};
+
+&pcie2_phy {
+ status = "okay";
+};
+
+&pcie1_rc {
+ num-lanes = <2>;
+ phys = <&pcie1_phy>, <&pcie2_phy>;
+ phy-names = "pcie-phy0", "pcie-phy1";
+};
+
+&pcie1_ep {
+ num-lanes = <2>;
+ phys = <&pcie1_phy>, <&pcie2_phy>;
+ phy-names = "pcie-phy0", "pcie-phy1";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 3/7] ARM: dts: DRA72x: Use PCIe compatible specific to dra72
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: Tony Lindgren, bcousson
Cc: Rob Herring, Mark Rutland, Russell King, linux-pci, devicetree,
linux-kernel, linux-omap, linux-arm-kernel, nsekhar, kishon
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
Use dra72 specific compatible string for PCIe while preserving
the older compatible.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra72x.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index 67107605fb4c..2dafad834d3d 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -50,3 +50,15 @@
status = "disabled";
};
};
+
+&pcie1_rc {
+ compatible = "ti,dra726-pcie-rc", "ti,dra7-pcie";
+};
+
+&pcie1_ep {
+ compatible = "ti,dra726-pcie-ep", "ti,dra7-pcie-ep";
+};
+
+&pcie2_rc {
+ compatible = "ti,dra726-pcie-rc", "ti,dra7-pcie";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/7] ARM: dts: DRA74x: Use PCIe compatible specific to dra74
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: Tony Lindgren, bcousson-rdvid1DuHRBWk0Htik3J/w
Cc: Rob Herring, Mark Rutland, Russell King,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nsekhar-l0cyMroinI0, kishon-l0cyMroinI0
In-Reply-To: <20171219093133.16565-1-kishon-l0cyMroinI0@public.gmane.org>
Use dra74 specific compatible string for PCIe while preserving
the older compatible. While at that add a new label for the
2nd instance of pcie.
Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/dra74x.dtsi | 12 ++++++++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9966d82dbd7c..333f6a634ff9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -349,7 +349,7 @@
ranges = <0x51800000 0x51800000 0x3000
0x0 0x30000000 0x10000000>;
status = "disabled";
- pcie@51800000 {
+ pcie2_rc: pcie@51800000 {
compatible = "ti,dra7-pcie";
reg = <0x51800000 0x2000>, <0x51802000 0x14c>, <0x1000 0x2000>;
reg-names = "rc_dbics", "ti_conf", "config";
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 24e6746c5b26..a001eecf3b14 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -124,3 +124,15 @@
status = "disabled";
};
};
+
+&pcie1_rc {
+ compatible = "ti,dra746-pcie-rc", "ti,dra7-pcie";
+};
+
+&pcie1_ep {
+ compatible = "ti,dra746-pcie-ep", "ti,dra7-pcie-ep";
+};
+
+&pcie2_rc {
+ compatible = "ti,dra746-pcie-rc", "ti,dra7-pcie";
+};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/7] ARM: dts: dra7: Add properties to enable PCIe x2 lane mode
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: Tony Lindgren, bcousson-rdvid1DuHRBWk0Htik3J/w
Cc: Rob Herring, Mark Rutland, Russell King,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nsekhar-l0cyMroinI0, kishon-l0cyMroinI0
In-Reply-To: <20171219093133.16565-1-kishon-l0cyMroinI0@public.gmane.org>
ti,syscon-lane-sel and ti,syscon-lane-conf properties specific to enable
PCIe x2 lane mode are added here.
Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/dra7.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ac9216293b7c..9966d82dbd7c 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -309,6 +309,8 @@
ti,hwmods = "pcie1";
phys = <&pcie1_phy>;
phy-names = "pcie-phy0";
+ ti,syscon-lane-conf = <&scm_conf 0x558>;
+ ti,syscon-lane-sel = <&scm_conf_pcie 0x18>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie1_intc 1>,
<0 0 0 2 &pcie1_intc 2>,
@@ -334,6 +336,8 @@
phys = <&pcie1_phy>;
phy-names = "pcie-phy0";
ti,syscon-unaligned-access = <&scm_conf1 0x14 2>;
+ ti,syscon-lane-conf = <&scm_conf 0x558>;
+ ti,syscon-lane-sel = <&scm_conf_pcie 0x18>;
status = "disabled";
};
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/7] ARM: dts: dra7: Enable x2 lane mode support
From: Kishon Vijay Abraham I @ 2017-12-19 9:31 UTC (permalink / raw)
To: Tony Lindgren, bcousson
Cc: Rob Herring, Mark Rutland, Russell King, linux-pci, devicetree,
linux-kernel, linux-omap, linux-arm-kernel, nsekhar, kishon
Add properties to enable PCIe x2 lane mode since all dra7
based SoCs support x2 lane mode.
However only dra76-evm has a slot which can support x2 lane
cards. Hence only enable x2 lane mode in dra76-evm.
(am571x-idk can support x2 lane mode but that makes usb port
not functional so not including the patch to enable
x2 mode in am571x-idk)
Also included in this series is patch to enable PCIe configs
(both host and device) in omap2plus_defconfig and
multi_v7_defconfig
In order to get x2 mode working [1] is required.
However by keeping the older compatible, this series won't
break functionality if this series is merged before [1]
[1] -> https://lkml.org/lkml/2017/12/19/175
Kishon Vijay Abraham I (7):
ARM: dts: dra7: Add properties to enable PCIe x2 lane mode
ARM: dts: DRA74x: Use PCIe compatible specific to dra74
ARM: dts: DRA72x: Use PCIe compatible specific to dra72
ARM: dts: dra76-evm: Enable x2 PCIe lanes
ARM: dts: dra7: Remove deprecated PCI compatible string
ARM: omap2plus_defconfig: Enable CONFIG_PCI_DRA7XX (Host & Device
modes)
ARM: multi_v7_defconfig: Enable CONFIG_PCI_DRA7XX (Host & Device
modes)
arch/arm/boot/dts/dra7.dtsi | 9 +++++----
arch/arm/boot/dts/dra72x.dtsi | 12 ++++++++++++
arch/arm/boot/dts/dra74x.dtsi | 12 ++++++++++++
arch/arm/boot/dts/dra76-evm.dts | 16 ++++++++++++++++
arch/arm/configs/multi_v7_defconfig | 6 ++++++
arch/arm/configs/omap2plus_defconfig | 8 ++++++++
6 files changed, 59 insertions(+), 4 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
From: Boris Brezillon @ 2017-12-19 9:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni, Nishanth Menon,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree
In-Reply-To: <20171219092119.GA32748@kroah.com>
On Tue, 19 Dec 2017 10:21:19 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> > On Tue, 19 Dec 2017 10:09:00 +0100
> > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> >
> > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > >
> > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > > > > +/**
> > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > + * @id_table: the I3C device ID table
> > > > > + *
> > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > > > + * no match.
> > > > > + */
> > > > > +const struct i3c_device_id *
> > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > + const struct i3c_device_id *id_table)
> > > > > +{
> > > > > + const struct i3c_device_id *id;
> > > > > +
> > > > > + /*
> > > > > + * The lower 32bits of the provisional ID is just filled with a random
> > > > > + * value, try to match using DCR info.
> > > > > + */
> > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > +
> > > > > + /* First try to match by manufacturer/part ID. */
> > > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > > > + I3C_MATCH_MANUF_AND_PART)
> > > > > + continue;
> > > > > +
> > > > > + if (manuf != id->manuf_id || part != id->part_id)
> > > > > + continue;
> > > > > +
> > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > + ext_info != id->extra_info)
> > > > > + continue;
> > > > > +
> > > > > + return id;
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + /* Fallback to DCR match. */
> > > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > + id->dcr == i3cdev->info.dcr)
> > > > > + return id;
> > > > > + }
> > > > > +
> > > > > + return NULL;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
> > > >
> > > > I just picked one random export here, but it feels like you are
> > > > exporting a bunch of symbols you don't need to. Why would something
> > > > outside of the i3c "core" need to call this function?
> > >
> > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > if the driver is supporting different variants of the device, it may
> > > want to know which one is being probed.
> > >
> > > I considered retrieving this information in the core just before probing
> > > the driver and passing it to the ->probe() function, but it means
> > > having an extra i3c_device_match_id() call for everyone even those who
> > > don't care about the device_id information, so I thought exporting this
> > > function was a good alternative (device drivers can use it when they
> > > actually need to retrieve the device_id).
> > >
> > > Anyway, that's something I can change if you think passing the
> > > i3c_device_id to the ->probe() method is preferable.
> > >
> > > > Have you looked
> > > > to see if you really have callers for everything you are exporting?
> > >
> > > Yes, I tried to only export functions that I think will be needed by
> > > I3C device drivers and I3C master drivers. Note that I didn't post the
> > > dummy device driver I developed to test the framework (partly because
> > > this is
> >
> > Sorry, I hit the send button before finishing my sentence :-).
> >
> > "
> > Note that I didn't post the dummy device driver [1] I developed to test
> > the framework (partly because the quality of the code does not meet
> > mainline standards and I was ashamed of posting it publicly :-)), but
> > this driver is using some of the exported functions.
> > "
>
> We don't export functions that has no in-kernel users :)
But then, I can't export device driver related functions, because
there's no official device driver yet :-). So what should I do?
^ permalink raw reply
* Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Sakari Ailus @ 2017-12-19 9:22 UTC (permalink / raw)
To: Wenyou Yang
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, linux-kernel,
Nicolas Ferre, devicetree, Jonathan Corbet, Hans Verkuil,
linux-arm-kernel, Linux Media Mailing List, Songjun Wu
In-Reply-To: <20171211013146.2497-3-wenyou.yang@microchip.com>
On Mon, Dec 11, 2017 at 09:31:46AM +0800, Wenyou Yang wrote:
> The ov7740 (color) image sensor is a high performance VGA CMOS
> image snesor, which supports for output formats: RAW RGB and YUV
> and image sizes: VGA, and QVGA, CIF and any size smaller.
>
> Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
> Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
Applied with this diff:
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
index 0308ba437bbb..041a77039d70 100644
--- a/drivers/media/i2c/ov7740.c
+++ b/drivers/media/i2c/ov7740.c
@@ -1,5 +1,7 @@
-// SPDX-License-Identifier: GPL-2.0
-// Copyright (c) 2017 Microchip Corporation.
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ * Copyright (c) 2017 Microchip Corporation.
+ */
#include <linux/clk.h>
#include <linux/delay.h>
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi
^ permalink raw reply related
* Re: [PATCH v14 0/5] ZII RAVE platform driver
From: Lee Jones @ 2017-12-19 9:22 UTC (permalink / raw)
To: Johan Hovold
Cc: Guenter Roeck, Andrey Smirnov, Pavel Machek, Greg Kroah-Hartman,
cphealy-Re5JQEeQqe8AvxtiuMwx3w, Andy Shevchenko, Lucas Stach,
Nikita Yushchenko, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
Andrew Morton
In-Reply-To: <20171219090624.GB8917@localhost>
On Tue, 19 Dec 2017, Johan Hovold wrote:
> On Tue, Dec 19, 2017 at 08:56:03AM +0000, Lee Jones wrote:
> > On Sat, 16 Dec 2017, Guenter Roeck wrote:
> > > On 12/07/2017 08:27 AM, Andrey Smirnov wrote:
> > > > Lee:
> > > >
> > > > This patch set has been marinating out there for a while now and
> > > > yours, I belive, is that last signature I need to start pushing it for
> > > > inclusion. I'd really appreciate if you could spare some of your time
> > > > to give it a look. Thanks!
> > > >
> > > > Everyone:
> > > >
> > > > This patch series is v14 of the driver for supervisory processor found
> > > > on RAVE series of devices from ZII. Supervisory processor is a PIC
> > > > microcontroller connected to various electrical subsystems on RAVE
> > > > devices whose firmware implements protocol to command/qery them.
> > > >
> > > > NOTE:
> > > >
> > > > * This driver dependends on crc_ccitt_false(), added by
> > > > 2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
> > > > was pulled in by Andrew Morton and is currently avaiting users, so
> > > > this series might have to go in through Andrew's tree
> > > >
> > >
> > > Strictly speaking, the solution would be for Andrew to provide an immutable
> > > branch with the above, for Rob to provide an immutable branch based on Andrew's
> > > branch, adding the serdev drivers, for Lee to provide yet another immutable
> > > branch with all those plus the mfd driver, and for Wim to pick it all up
> > > into the watchdog tree.
> >
> > I think that's the craziest thing I've ever heard. ;) Only 1
> > immutable branch is required, which can be pulled in by everyone.
> >
> > Bear with me. Pull-request to follow.
>
> Did the compatible-strings issue get sorted out? That is, that the cell
> drivers were matching on the parent compatible string to determine
> their type instead of encoding that in their own compatible strings. Is
> that desired (and recommended)?
Looks like they are still doing that.
I'd suggest that it was sub-optimal. It would be better to pass
platform information through pdata or ddata IMHO. Or yes, use the
child compatible strings (if they differ from platform to platform).
--
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6] mfd: syscon: Add hardware spinlock support
From: Mark Brown @ 2017-12-19 9:21 UTC (permalink / raw)
To: Baolin Wang
Cc: Arnd Bergmann, Lee Jones, Rob Herring, Mark Rutland,
Linux Kernel Mailing List, DTML
In-Reply-To: <CAMz4kuK2JRSZt6BiYu+YRy_+kXNen+NTgayqpXy1n3qL-T9OzQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 772 bytes --]
On Tue, Dec 19, 2017 at 02:55:47PM +0800, Baolin Wang wrote:
> Um, why regmap doesn't accept a zero lock-id, that because regmap will
> reguest hwlock depending on the 'regmap_config->hwlock_id' is not
> zero, if regmap regard a zero lock-id as valid which will affect other
> 'struct regmap_config' definition. So users should not assign the zero
> lock-id to regmap.
> Now of_hwspin_lock_get_id() can return 0 as valid, which depend on
> what is the base id registered by hwspinlock driver. So you think we
> should not regard 0 as valid from of_hwspin_lock_get_id(), I can try
> to send another patch to fix.
If 0 is a valid hwspinlock ID you need to add a flag to the regmap
config to say if a hwspinlock should be used. That way we're not
rejecting valid values.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
From: Greg Kroah-Hartman @ 2017-12-19 9:21 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171219101336.337d0afc@bbrezillon>
On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> On Tue, 19 Dec 2017 10:09:00 +0100
> Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > On Tue, 19 Dec 2017 09:52:50 +0100
> > Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> >
> > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > > > +/**
> > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > > + * @i3cdev: the I3C device we're searching a match for
> > > > + * @id_table: the I3C device ID table
> > > > + *
> > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > > + * no match.
> > > > + */
> > > > +const struct i3c_device_id *
> > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > + const struct i3c_device_id *id_table)
> > > > +{
> > > > + const struct i3c_device_id *id;
> > > > +
> > > > + /*
> > > > + * The lower 32bits of the provisional ID is just filled with a random
> > > > + * value, try to match using DCR info.
> > > > + */
> > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > +
> > > > + /* First try to match by manufacturer/part ID. */
> > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > > + I3C_MATCH_MANUF_AND_PART)
> > > > + continue;
> > > > +
> > > > + if (manuf != id->manuf_id || part != id->part_id)
> > > > + continue;
> > > > +
> > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > + ext_info != id->extra_info)
> > > > + continue;
> > > > +
> > > > + return id;
> > > > + }
> > > > + }
> > > > +
> > > > + /* Fallback to DCR match. */
> > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > + id->dcr == i3cdev->info.dcr)
> > > > + return id;
> > > > + }
> > > > +
> > > > + return NULL;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
> > >
> > > I just picked one random export here, but it feels like you are
> > > exporting a bunch of symbols you don't need to. Why would something
> > > outside of the i3c "core" need to call this function?
> >
> > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > if the driver is supporting different variants of the device, it may
> > want to know which one is being probed.
> >
> > I considered retrieving this information in the core just before probing
> > the driver and passing it to the ->probe() function, but it means
> > having an extra i3c_device_match_id() call for everyone even those who
> > don't care about the device_id information, so I thought exporting this
> > function was a good alternative (device drivers can use it when they
> > actually need to retrieve the device_id).
> >
> > Anyway, that's something I can change if you think passing the
> > i3c_device_id to the ->probe() method is preferable.
> >
> > > Have you looked
> > > to see if you really have callers for everything you are exporting?
> >
> > Yes, I tried to only export functions that I think will be needed by
> > I3C device drivers and I3C master drivers. Note that I didn't post the
> > dummy device driver I developed to test the framework (partly because
> > this is
>
> Sorry, I hit the send button before finishing my sentence :-).
>
> "
> Note that I didn't post the dummy device driver [1] I developed to test
> the framework (partly because the quality of the code does not meet
> mainline standards and I was ashamed of posting it publicly :-)), but
> this driver is using some of the exported functions.
> "
We don't export functions that has no in-kernel users :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board
From: Alexandre Torgue @ 2017-12-19 9:17 UTC (permalink / raw)
To: Arnd Bergmann, Ludovic Barre
Cc: Russell King, Rob Herring, Linus Walleij, Maxime Coquelin,
Gerald Baeza, Linux ARM, Linux Kernel Mailing List, DTML
In-Reply-To: <CAK8P3a14KzxGK8j75UUBfWgexg2fdzrtdgcqUT=uHfjWrVaWbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 12/18/2017 09:20 PM, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre-qxv4g6HH51o@public.gmane.org> wrote:
> =
>> +
>> +/ {
>> + model = "STMicroelectronics STM32MP157C eval daughter";
>> + compatible = "st,stm32mp157c-ed1", "st,stm32mp157";
>> +
>> + chosen {
>> + bootargs = "earlyprintk console=ttySTM3,115200 root=/dev/ram";
>> + stdout-path = "serial3:115200n8";
>> + };
>
> I'd remove the bootargs here and let the boot loader take care of
> that, in particular
> since all three arguments are rather old-school: earlycon is preferred over
> earlyprintk, console= should not be needed if you set stdout-path, and
> /dev/ram is obsoleted by initramfs.
In this case I will modify also stm32 mcu devicetree in this way.
Thanks
Alex
>
> Arnd
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
From: Boris Brezillon @ 2017-12-19 9:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni, Nishanth Menon,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree
In-Reply-To: <20171219100900.35c0f66e@bbrezillon>
On Tue, 19 Dec 2017 10:09:00 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Tue, 19 Dec 2017 09:52:50 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > > +/**
> > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > + * @i3cdev: the I3C device we're searching a match for
> > > + * @id_table: the I3C device ID table
> > > + *
> > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > + * no match.
> > > + */
> > > +const struct i3c_device_id *
> > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > + const struct i3c_device_id *id_table)
> > > +{
> > > + const struct i3c_device_id *id;
> > > +
> > > + /*
> > > + * The lower 32bits of the provisional ID is just filled with a random
> > > + * value, try to match using DCR info.
> > > + */
> > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > +
> > > + /* First try to match by manufacturer/part ID. */
> > > + for (id = id_table; id->match_flags != 0; id++) {
> > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > + I3C_MATCH_MANUF_AND_PART)
> > > + continue;
> > > +
> > > + if (manuf != id->manuf_id || part != id->part_id)
> > > + continue;
> > > +
> > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > + ext_info != id->extra_info)
> > > + continue;
> > > +
> > > + return id;
> > > + }
> > > + }
> > > +
> > > + /* Fallback to DCR match. */
> > > + for (id = id_table; id->match_flags != 0; id++) {
> > > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > > + id->dcr == i3cdev->info.dcr)
> > > + return id;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
> >
> > I just picked one random export here, but it feels like you are
> > exporting a bunch of symbols you don't need to. Why would something
> > outside of the i3c "core" need to call this function?
>
> Because I'm not passing the i3c_device_id to the ->probe() method, and
> if the driver is supporting different variants of the device, it may
> want to know which one is being probed.
>
> I considered retrieving this information in the core just before probing
> the driver and passing it to the ->probe() function, but it means
> having an extra i3c_device_match_id() call for everyone even those who
> don't care about the device_id information, so I thought exporting this
> function was a good alternative (device drivers can use it when they
> actually need to retrieve the device_id).
>
> Anyway, that's something I can change if you think passing the
> i3c_device_id to the ->probe() method is preferable.
>
> > Have you looked
> > to see if you really have callers for everything you are exporting?
>
> Yes, I tried to only export functions that I think will be needed by
> I3C device drivers and I3C master drivers. Note that I didn't post the
> dummy device driver I developed to test the framework (partly because
> this is
Sorry, I hit the send button before finishing my sentence :-).
"
Note that I didn't post the dummy device driver [1] I developed to test
the framework (partly because the quality of the code does not meet
mainline standards and I was ashamed of posting it publicly :-)), but
this driver is using some of the exported functions.
"
[1]https://github.com/bbrezillon/linux-0day/commit/10054caf3493524b6ae352a1bdcb71e82c885a6e
^ permalink raw reply
* Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Sakari Ailus @ 2017-12-19 9:11 UTC (permalink / raw)
To: Wenyou.Yang-UWL1GkI3JZL3oGB3hsPCZA
Cc: mchehab-JsYNTwtnfakRB7SZvlqPiA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Nicolas.Ferre-UWL1GkI3JZL3oGB3hsPCZA,
devicetree-u79uwXL29TY76Z2rM5mHXA, corbet-T1hC0tSOHrs,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <F9F4555C4E01D7469D37975B62D0EFBB8DDA56-8fD0d2gESGoGk1ErWP88zX2Vsf1/G1/XQQ4Iyu8u01E@public.gmane.org>
Hi Wenyou,
On Tue, Dec 19, 2017 at 02:11:28AM +0000, Wenyou.Yang-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org wrote:
> Hi Sakari,
>
> > -----Original Message-----
> > From: Sakari Ailus [mailto:sakari.ailus-X3B1VOXEql0@public.gmane.org]
> > Sent: 2017年12月14日 4:06
> > To: Wenyou Yang - A41535 <Wenyou.Yang-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>; Mauro Carvalho
> > Chehab <mchehab-JsYNTwtnfakRB7SZvlqPiA@public.gmane.org>; Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>;
> > Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Nicolas Ferre - M43238
> > <Nicolas.Ferre-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Jonathan Corbet
> > <corbet-T1hC0tSOHrs@public.gmane.org>; Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>; linux-arm-
> > kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Linux Media Mailing List <linux-
> > media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; Songjun Wu <songjun.wu-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> > Subject: Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
> >
> > Hi Wenyou,
> >
> > Wenyou Yang wrote:
> > ...
> > > +static int ov7740_start_streaming(struct ov7740 *ov7740) {
> > > + int ret;
> > > +
> > > + if (ov7740->fmt) {
> > > + ret = regmap_multi_reg_write(ov7740->regmap,
> > > + ov7740->fmt->regs,
> > > + ov7740->fmt->reg_num);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > + if (ov7740->frmsize) {
> > > + ret = regmap_multi_reg_write(ov7740->regmap,
> > > + ov7740->frmsize->regs,
> > > + ov7740->frmsize->reg_num);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > + return __v4l2_ctrl_handler_setup(ov7740->subdev.ctrl_handler);
> >
> > I believe you're still setting the controls after starting streaming.
>
> Yes, it sees it does so.
>
> The OV7740 sensor generates the stream pixel data at the constant frame
> rate, no such start or stop control.
That'd be odd but I guess hardware sometimes is. I'll apply the patches.
Thanks!
--
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] touchscreen: mms114: add support for mms152
From: Andi Shyti @ 2017-12-19 9:10 UTC (permalink / raw)
To: Simon Shields
Cc: Dmitry Torokhov, linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171219080409.GA27703-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
Hi Simon,
> > > #ifdef CONFIG_OF
> > > static const struct of_device_id mms114_dt_match[] = {
> > > - { .compatible = "melfas,mms114" },
> > > + {
> > > + .compatible = "melfas,mms114",
> > > + .data = (void *)TYPE_MMS114,
> > > + }, {
> > > + .compatible = "melfas,mms152",
> > > + .data = (void *)TYPE_MMS152,
> >
> > You are not documenting the new "melfas,mms152" compatible in
> > Documentation/devicetree/bindings/input/touchscreen/mms114.txt
>
> Yes I am - "melfas,mms152" is added to the documentation
> as part of this patch. Is there something wrong with what I've done
> there?
Oh yes, sorry! I missed it while snipping the code :)
Please ignore this comment, then.
Andi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
From: Boris Brezillon @ 2017-12-19 9:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni, Nishanth Menon,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree
In-Reply-To: <20171219085250.GC15010@kroah.com>
On Tue, 19 Dec 2017 09:52:50 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > +/**
> > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > + * @i3cdev: the I3C device we're searching a match for
> > + * @id_table: the I3C device ID table
> > + *
> > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > + * no match.
> > + */
> > +const struct i3c_device_id *
> > +i3c_device_match_id(struct i3c_device *i3cdev,
> > + const struct i3c_device_id *id_table)
> > +{
> > + const struct i3c_device_id *id;
> > +
> > + /*
> > + * The lower 32bits of the provisional ID is just filled with a random
> > + * value, try to match using DCR info.
> > + */
> > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > +
> > + /* First try to match by manufacturer/part ID. */
> > + for (id = id_table; id->match_flags != 0; id++) {
> > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > + I3C_MATCH_MANUF_AND_PART)
> > + continue;
> > +
> > + if (manuf != id->manuf_id || part != id->part_id)
> > + continue;
> > +
> > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > + ext_info != id->extra_info)
> > + continue;
> > +
> > + return id;
> > + }
> > + }
> > +
> > + /* Fallback to DCR match. */
> > + for (id = id_table; id->match_flags != 0; id++) {
> > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > + id->dcr == i3cdev->info.dcr)
> > + return id;
> > + }
> > +
> > + return NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
>
> I just picked one random export here, but it feels like you are
> exporting a bunch of symbols you don't need to. Why would something
> outside of the i3c "core" need to call this function?
Because I'm not passing the i3c_device_id to the ->probe() method, and
if the driver is supporting different variants of the device, it may
want to know which one is being probed.
I considered retrieving this information in the core just before probing
the driver and passing it to the ->probe() function, but it means
having an extra i3c_device_match_id() call for everyone even those who
don't care about the device_id information, so I thought exporting this
function was a good alternative (device drivers can use it when they
actually need to retrieve the device_id).
Anyway, that's something I can change if you think passing the
i3c_device_id to the ->probe() method is preferable.
> Have you looked
> to see if you really have callers for everything you are exporting?
Yes, I tried to only export functions that I think will be needed by
I3C device drivers and I3C master drivers. Note that I didn't post the
dummy device driver I developed to test the framework (partly because
this is
>
> Other than that, the driver core interaction looks good now, nice job.
Thanks.
Boris
^ permalink raw reply
* Re: [PATCH v14 0/5] ZII RAVE platform driver
From: Johan Hovold @ 2017-12-19 9:06 UTC (permalink / raw)
To: Lee Jones
Cc: Guenter Roeck, Andrey Smirnov, Pavel Machek, Greg Kroah-Hartman,
cphealy-Re5JQEeQqe8AvxtiuMwx3w, Andy Shevchenko, Lucas Stach,
Nikita Yushchenko, Rob Herring, Mark Rutland, Johan Hovold,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
Andrew Morton
In-Reply-To: <20171219085603.nk6x25b7kkc2rukz@dell>
On Tue, Dec 19, 2017 at 08:56:03AM +0000, Lee Jones wrote:
> On Sat, 16 Dec 2017, Guenter Roeck wrote:
> > On 12/07/2017 08:27 AM, Andrey Smirnov wrote:
> > > Lee:
> > >
> > > This patch set has been marinating out there for a while now and
> > > yours, I belive, is that last signature I need to start pushing it for
> > > inclusion. I'd really appreciate if you could spare some of your time
> > > to give it a look. Thanks!
> > >
> > > Everyone:
> > >
> > > This patch series is v14 of the driver for supervisory processor found
> > > on RAVE series of devices from ZII. Supervisory processor is a PIC
> > > microcontroller connected to various electrical subsystems on RAVE
> > > devices whose firmware implements protocol to command/qery them.
> > >
> > > NOTE:
> > >
> > > * This driver dependends on crc_ccitt_false(), added by
> > > 2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
> > > was pulled in by Andrew Morton and is currently avaiting users, so
> > > this series might have to go in through Andrew's tree
> > >
> >
> > Strictly speaking, the solution would be for Andrew to provide an immutable
> > branch with the above, for Rob to provide an immutable branch based on Andrew's
> > branch, adding the serdev drivers, for Lee to provide yet another immutable
> > branch with all those plus the mfd driver, and for Wim to pick it all up
> > into the watchdog tree.
>
> I think that's the craziest thing I've ever heard. ;) Only 1
> immutable branch is required, which can be pulled in by everyone.
>
> Bear with me. Pull-request to follow.
Did the compatible-strings issue get sorted out? That is, that the cell
drivers were matching on the parent compatible string to determine
their type instead of encoding that in their own compatible strings. Is
that desired (and recommended)?
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox