Hi Neil,
On 31 October 2016 at 11:54, Neil Armstrong <narmstr...@baylibre.com> wrote:
> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>
> Acked-by: Joachim Eastwood <manab...@gmail.com>
> Signed-off-by: Neil Armstrong <narmstr...@baylib
Hi Neil,
On 31 October 2016 at 11:54, Neil Armstrong wrote:
> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>
> Acked-by: Joachim Eastwood
> Signed-off-by: Neil Armstrong
> ---
> +static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
> +{
&
You can see in the boot log:
>From lpc18xx boot:
[3.242253] stmmac - user ID: 0x11, Synopsys ID: 0x36
[3.247653] Ring mode enabled
[3.251491] DMA HW capability register supported
[3.256336] Enhanced/Alternate descriptors
[3.261537] Enabled extended descriptors
[3.265968] RX Checksum Offload Engine supported (type 2)
[3.272249] TX Checksum insertion supported
[3.276874] Wake-Up On Lan supported
[3.283743] Enable RX Mitigation via HW Watchdog Timer
[3.326701] libphy: stmmac: probed
Synopsys ID: 0x36 and user UD: 0x11, gives us DWMAC version 3.611
regards,
Joachim Eastwood
2253] stmmac - user ID: 0x11, Synopsys ID: 0x36
[3.247653] Ring mode enabled
[3.251491] DMA HW capability register supported
[3.256336] Enhanced/Alternate descriptors
[3.261537] Enabled extended descriptors
[3.265968] RX Checksum Offload Engine supported (type 2)
[3.272249] TX Checksum insertion supported
[3.276874] Wake-Up On Lan supported
[3.283743] Enable RX Mitigation via HW Watchdog Timer
[3.326701] libphy: stmmac: probed
Synopsys ID: 0x36 and user UD: 0x11, gives us DWMAC version 3.611
regards,
Joachim Eastwood
21125 device with the rtc-pcf8563 driver?
You will need to add a regmap layer since the PCA21125 is SPI while
the PCF8563 is I2C.
regards,
Joachim Eastwood
r?
You will need to add a regmap layer since the PCA21125 is SPI while
the PCF8563 is I2C.
regards,
Joachim Eastwood
).
Can you use that driver instead of creating a new one? If so; send a
patch for rtc-pcf8563 that adds "pca8565" to the set of i2c ids.
regards,
Joachim Eastwood
ing a new one? If so; send a
patch for rtc-pcf8563 that adds "pca8565" to the set of i2c ids.
regards,
Joachim Eastwood
t; +#ifdef CONFIG_PM_SLEEP
> +static int oxnas_dwmac_suspend(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + struct oxnas_dwmac *dwmac = priv->plat->bsp_priv;
get_stmmac_bsp_priv()
> + int ret;
> +
> + ret = stmmac_suspend(dev);
> + clk_disable_unprepare(dwmac->clk);
> +
> + return ret;
> +}
> +
> +static int oxnas_dwmac_resume(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + struct oxnas_dwmac *dwmac = priv->plat->bsp_priv;
get_stmmac_bsp_priv()
> + int ret;
> +
> + ret = oxnas_dwmac_init(dwmac);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_resume(dev);
> +
> + return ret;
> +}
> +#endif /* CONFIG_PM_SLEEP */
With these changes:
Acked-by: Joachim Eastwood <manab...@gmail.com>
best regards,
Joachim Eastwood
truct stmmac_priv *priv = netdev_priv(ndev);
> + struct oxnas_dwmac *dwmac = priv->plat->bsp_priv;
get_stmmac_bsp_priv()
> + int ret;
> +
> + ret = stmmac_suspend(dev);
> + clk_disable_unprepare(dwmac->clk);
> +
> + return ret;
> +}
> +
> +static int oxnas_dwmac_resume(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + struct oxnas_dwmac *dwmac = priv->plat->bsp_priv;
get_stmmac_bsp_priv()
> + int ret;
> +
> + ret = oxnas_dwmac_init(dwmac);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_resume(dev);
> +
> + return ret;
> +}
> +#endif /* CONFIG_PM_SLEEP */
With these changes:
Acked-by: Joachim Eastwood
best regards,
Joachim Eastwood
s instead. I.e: PM resume/suspend and driver remove.
Shouldn't you call oxnas_dwmac_init() from probe as well?
As it is now it will only be called during PM resume and that can't be right.
> +
> + return stmmac_dvr_probe(>dev, plat_dat, _res);
If stmmac_dvr_probe() fails you should disable your clocks.
regards,
Joachim Eastwood
xnas_dwmac_init() from probe as well?
As it is now it will only be called during PM resume and that can't be right.
> +
> + return stmmac_dvr_probe(>dev, plat_dat, _res);
If stmmac_dvr_probe() fails you should disable your clocks.
regards,
Joachim Eastwood
Hi Arvind,
On 20 September 2016 at 12:39, Arvind Yadav <arvind.yadav...@gmail.com> wrote:
> From: Arvind Yadav <arvind.yadav...@gmail.com>
>
> Free memory mapping, if lpc18xx_ccu_init is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com>
Hi Arvind,
On 20 September 2016 at 12:39, Arvind Yadav wrote:
> From: Arvind Yadav
>
> Free memory mapping, if lpc18xx_ccu_init is not successful.
>
> Signed-off-by: Arvind Yadav
Acked-by: Joachim Eastwood
One comment below:
> ---
> drivers/clk/nxp/clk-lpc18xx-ccu.c |
t(struct gpio_chip
> *chip,
> return lpc18xx_gpio_direction(chip, offset, true);
> }
>
> -static struct gpio_chip lpc18xx_chip = {
> +static const struct gpio_chip lpc18xx_chip = {
> .label = "lpc18xx/43xx-gpio",
> .request= gpiochip_generic_request,
> .free = gpiochip_generic_free,
For lpc18xx:
Acked-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
ion(chip, offset, true);
> }
>
> -static struct gpio_chip lpc18xx_chip = {
> +static const struct gpio_chip lpc18xx_chip = {
> .label = "lpc18xx/43xx-gpio",
> .request= gpiochip_generic_request,
> .free = gpiochip_generic_free,
For lpc18xx:
Acked-by: Joachim Eastwood
regards,
Joachim Eastwood
Hi Philipp,
On 24 August 2016 at 15:28, Philipp Zabel <p.za...@pengutronix.de> wrote:
> Visible only if COMPILE_TEST is enabled, this allows to include the
> driver in build tests.
>
> Cc: Joachim Eastwood <manab...@gmail.com>
> Signed-off-by: Philipp Za
Hi Philipp,
On 24 August 2016 at 15:28, Philipp Zabel wrote:
> Visible only if COMPILE_TEST is enabled, this allows to include the
> driver in build tests.
>
> Cc: Joachim Eastwood
> Signed-off-by: Philipp Zabel
> ---
> drivers/reset/Kconfig | 7 +++
> drivers/re
patch or break it out. But
> for
> reviewing, avoiding the patch bomb is probably a good thing.
>
> Should go via subsystem tree, I'd think.
>
> Wolfram Sang (1):
> i2c: don't print error when adding adapter fails
For
> drivers/i2c/busses/i2c-lpc2k.c | 4 +---
Acked-by: Jo
; reviewing, avoiding the patch bomb is probably a good thing.
>
> Should go via subsystem tree, I'd think.
>
> Wolfram Sang (1):
> i2c: don't print error when adding adapter fails
For
> drivers/i2c/busses/i2c-lpc2k.c | 4 +---
Acked-by: Joachim Eastwood
regards,
Joachim Eastwood
return ERR_PTR(-ENOMEM);
> +
> + parse_dt = (const void *)of_id->data;
You can retrieve OF match data using of_device_get_match_data(). Saves
you a couple of lines and better explains what your doing.
> + if (parse_dt)
> + err = parse_dt(pdev, pdata, flags);
> + if (err)
> + return ERR_PTR(err);
> +
> + return pdata;
> +}
regards,
Joachim Eastwood
ve OF match data using of_device_get_match_data(). Saves
you a couple of lines and better explains what your doing.
> + if (parse_dt)
> + err = parse_dt(pdev, pdata, flags);
> + if (err)
> + return ERR_PTR(err);
> +
> + return pdata;
> +}
regards,
Joachim Eastwood
ext.com>
> ---
Acked-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
On 1 May 2016 at 12:36, Masahiro Yamada wrote:
> Use devm_reset_controller_register() for the reset controller
> registration and remove the unregister call from the .remove callback.
>
> Signed-off-by: Masahiro Yamada
> ---
Acked-by: Joachim Eastwood
regards,
Joachim Eastwood
m->polarity == PWM_POLARITY_NORMAL) {
> + if (pwm_get_polarity(pwm) == PWM_POLARITY_NORMAL) {
> set_event = lpc18xx_pwm->period_event;
> clear_event = lpc18xx_data->duty_event;
> res_action = LPC18XX_PWM_RES_SET;
For the lpc18xx-sct part:
Acked-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
RITY_NORMAL) {
> set_event = lpc18xx_pwm->period_event;
> clear_event = lpc18xx_data->duty_event;
> res_action = LPC18XX_PWM_RES_SET;
For the lpc18xx-sct part:
Acked-by: Joachim Eastwood
regards,
Joachim Eastwood
Hi Marc,
On 11 April 2016 at 17:15, Marc Zyngier <marc.zyng...@arm.com> wrote:
> Hi Joachim,
>
> On 02/04/16 17:35, Joachim Eastwood wrote:
>> Signed-off-by: Joachim Eastwood <manab...@gmail.com>
>
> As a start, a commit message would be appreciated.
Ops
Hi Marc,
On 11 April 2016 at 17:15, Marc Zyngier wrote:
> Hi Joachim,
>
> On 02/04/16 17:35, Joachim Eastwood wrote:
>> Signed-off-by: Joachim Eastwood
>
> As a start, a commit message would be appreciated.
Ops! I wonder where that disappeared to. The previous versio
On 10 April 2016 at 14:47, Joachim Eastwood <manab...@gmail.com> wrote:
> Hi Cristina,
>
> On 9 April 2016 at 10:24, Cristina Moraru <cristina.morar...@gmail.com> wrote:
>> Add implementation for Maxim MAX5487, MAX5488, MAX5489
>> digital potenti
On 10 April 2016 at 14:47, Joachim Eastwood wrote:
> Hi Cristina,
>
> On 9 April 2016 at 10:24, Cristina Moraru wrote:
>> Add implementation for Maxim MAX5487, MAX5488, MAX5489
>> digital potentiometers.
>>
>> Datasheet:
>> http://datasheets.maximi
regmap here, but since you are only using
simple regmap_write()'s you might as well have used spi_write()
directly. I am not telling you to switch, but I don't see the point of
using regmap here.
Which reminds me; for regmap you need to select REGMAP_SPI in your
Kconfig entry.
regards,
Joachim Eastwood
rite()
directly. I am not telling you to switch, but I don't see the point of
using regmap here.
Which reminds me; for regmap you need to select REGMAP_SPI in your
Kconfig entry.
regards,
Joachim Eastwood
7455)
> {
> + struct device *dev = regmap_get_device(mma7455->regmap);
ah, nice!
Acked-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
l/mma7455_core.c
> +++ b/drivers/iio/accel/mma7455_core.c
> @@ -55,11 +55,11 @@
>
> struct mma7455_data {
> struct regmap *regmap;
> - struct device *dev;
> };
>
> static int mma7455_drdy(struct mma7455_data *mma7455)
> {
> + struct device *dev = regmap_get
Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
controller.
Signed-off-by: Joachim Eastwood <manab...@gmail.com>
---
.../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644
Documentation/devi
Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
controller.
Signed-off-by: Joachim Eastwood
---
.../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt
Signed-off-by: Joachim Eastwood <manab...@gmail.com>
---
drivers/irqchip/Kconfig | 5 +
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-lpc18xx-gpio-pint.c | 219
3 files changed, 225 insertions(+)
create mode 100644 d
- describe the interrupts property better in dt doc
Joachim Eastwood (2):
irqchip: add lpc18xx gpio pin interrupt driver
devicetree: document NXP LPC1850 PINT irq controller binding
.../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 26 +++
drivers/irqchip/Kconfig
Signed-off-by: Joachim Eastwood
---
drivers/irqchip/Kconfig | 5 +
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-lpc18xx-gpio-pint.c | 219
3 files changed, 225 insertions(+)
create mode 100644 drivers/irqchip/irq-lpc18xx
- describe the interrupts property better in dt doc
Joachim Eastwood (2):
irqchip: add lpc18xx gpio pin interrupt driver
devicetree: document NXP LPC1850 PINT irq controller binding
.../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 26 +++
drivers/irqchip/Kconfig
controller {
> + nvic: nv-interrupt-controller@0xe000e100 {
While changing the line it might be good idea to use the standard
'interrupt-controller' name instead.
I posted the same patch couple of days ago, btw.
http://marc.info/?l=devicetree=145929088915714=2
But I don't care which one that is applied.
regards,
Joachim Eastwood
-controller@0xe000e100 {
While changing the line it might be good idea to use the standard
'interrupt-controller' name instead.
I posted the same patch couple of days ago, btw.
http://marc.info/?l=devicetree=145929088915714=2
But I don't care which one that is applied.
regards,
Joachim Eastwood
e you make this change.
$ scripts/dtc/dtc -I dtb -O dts arch/arm/boot/dts/s3c2416-smdk2416.dtb
| grep -A2 memory
memory {
device_type = "memory";
reg = <0x0 0x0>;
};
--
memory@3000 {
reg = <0x3000 0x400>;
};
regards,
Joachim Eastwood
[1] http://marc.info/?l=linux-arm-kernel=145933287125938=2
arch/arm/boot/dts/s3c2416-smdk2416.dtb
| grep -A2 memory
memory {
device_type = "memory";
reg = <0x0 0x0>;
};
--
memory@3000 {
reg = <0x3000 0x400>;
};
regards,
Joachim Eastwood
[1] http://marc.info/?l=linux-arm-kernel=145933287125938=2
end
> it. Often reviewers don't get enough credit in my opinion!
Sure;
Reviewed-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
ngpong with it.
>
> A very nice, clean driver. Thanks for your hard work on this.
>
> Note it is in a branch I happy to rebase for the next week, so if Joachim
> in particular would like to add a reviewed by tag, I'd be delighted to append
> it. Often reviewers don't get enou
data->buf[1] = val & 0xFF; /* 8 bits here */
> +
> + err = spi_write(data->spi, data->buf, 2);
> + if (err) {
> + mutex_unlock(>lock);
> + return err;
> + }
> + mutex_unlock(>lock);
> +
> + return 0;
This last part could be written as:
err = spi_write(data->spi, data->buf, 2);
mutex_unlock(>lock);
return err;
Other than the things I noted driver looks good to me.
regards,
Joachim Eastwood
bits here */
> +
> + err = spi_write(data->spi, data->buf, 2);
> + if (err) {
> + mutex_unlock(>lock);
> + return err;
> + }
> + mutex_unlock(>lock);
> +
> + return 0;
This last part could be written as:
err = spi_write(data->spi, data->buf, 2);
mutex_unlock(>lock);
return err;
Other than the things I noted driver looks good to me.
regards,
Joachim Eastwood
s
to the IP block doc from Synopsys should be able to check which clocks
the MAC really needs.
Rockchip bindings have two clocks named "mac_clk_rx" and "mac_clk_tx".
These are probably the same as stm32 needs so maybe use these names
and move them into the main doc and update the rockchip binding.
regards,
Joachim Eastwood
d be able to check which clocks
the MAC really needs.
Rockchip bindings have two clocks named "mac_clk_rx" and "mac_clk_tx".
These are probably the same as stm32 needs so maybe use these names
and move them into the main doc and update the rockchip binding.
regards,
Joachim Eastwood
Since Alexandre has not added "snps,dwmac-3.50a" to dwmac-generic
doesn't he use it as you suggest here?
Note that we can not remove all the generic compatible strings from
dwmac-generic because there is one platform that depend on one of
them.
(see arch/arm/boot/dts/exynos5440.dtsi:190)
So we can not remove "snps,dwmac-3.70a" from the dwmac-generic driver
if we want to keep backwards compatibility with exynos5440. But I
guess we could remove the others if we want to.
regards,
Joachim Eastwood
n better if the versioned strings were
> only used to indicate functionality, and not used to bind
> the drivers. But the bindings were set some time ago.
Since Alexandre has not added "snps,dwmac-3.50a" to dwmac-generic
doesn't he use it as you suggest here?
Note that we can not remove all the generic compatible strings from
dwmac-generic because there is one platform that depend on one of
them.
(see arch/arm/boot/dts/exynos5440.dtsi:190)
So we can not remove "snps,dwmac-3.70a" from the dwmac-generic driver
if we want to keep backwards compatibility with exynos5440. But I
guess we could remove the others if we want to.
regards,
Joachim Eastwood
Hi Jonathan,
On 20 March 2016 at 18:25, Jonathan Cameron <ji...@kernel.org> wrote:
> On 20/03/16 16:12, Joachim Eastwood wrote:
>>> +static int mcp4131_exec(struct mcp4131_data *data,
>>> + u8 addr, u8 cmd,
>>> + u16 val)
>>&g
Hi Jonathan,
On 20 March 2016 at 18:25, Jonathan Cameron wrote:
> On 20/03/16 16:12, Joachim Eastwood wrote:
>>> +static int mcp4131_exec(struct mcp4131_data *data,
>>> + u8 addr, u8 cmd,
>>> + u16 val)
>>> +{
>>> +
ck);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (val > data->cfg->max_pos || val < 0) {
> + mutex_unlock(>lock);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mutex_unlock(>lock);
> + return -EINVAL;
> + }
> +
> + err = mcp4131_exec(data, address, MCP4131_WRITE, val);
> + mutex_unlock(>lock);
While this is not a huge function it is usually good practice to keep
the locking scope as small as possible.
So wouldn't this be sufficient here.
mutex_lock(>lock);
err = mcp4131_exec(data, address, MCP4131_WRITE, val);
mutex_unlock(>lock);
Of course if you are able move the lock into mcp4131_exec this will go away.
regards,
Joachim Eastwood
case IIO_CHAN_INFO_RAW:
> + if (val > data->cfg->max_pos || val < 0) {
> + mutex_unlock(>lock);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mutex_unlock(>lock);
> + return -EINVAL;
> + }
> +
> + err = mcp4131_exec(data, address, MCP4131_WRITE, val);
> + mutex_unlock(>lock);
While this is not a huge function it is usually good practice to keep
the locking scope as small as possible.
So wouldn't this be sufficient here.
mutex_lock(>lock);
err = mcp4131_exec(data, address, MCP4131_WRITE, val);
mutex_unlock(>lock);
Of course if you are able move the lock into mcp4131_exec this will go away.
regards,
Joachim Eastwood
> + dev_err(>dev, "pwm clock has no frequency\n");
> + ret = -EINVAL;
> + goto disable_pwmclk;
> + }
Acked-by: Joachim Eastwood <manab...@gmail.com>
Thanks for fixing this.
regards,
Joachim Eastwood
8xx_pwm_probe(struct platform_device
> *pdev)
> }
>
> lpc18xx_pwm->clk_rate = clk_get_rate(lpc18xx_pwm->pwm_clk);
> + if (!lpc18xx_pwm->clk_rate) {
> + dev_err(>dev, "pwm clock has no frequency\n");
> + ret =
k);
> + if (!lpc18xx_pwm->clk_rate)
> + return -EINVAL;
This needs to be:
if (!lpc18xx_pwm->clk_rate) {
ret = -EINVAL;
goto disable_pwmclk;
}
I would also prefer an explicit check against 0 here. ie.:
'lpc18xx_pwm->clk_rate == 0'
A dev_err() message would also be nice to have.
regards,
Joachim Eastwood
pc18xx_pwm->clk_rate) {
ret = -EINVAL;
goto disable_pwmclk;
}
I would also prefer an explicit check against 0 here. ie.:
'lpc18xx_pwm->clk_rate == 0'
A dev_err() message would also be nice to have.
regards,
Joachim Eastwood
On 2 March 2016 at 19:13, Rob Herring <r...@kernel.org> wrote:
> On Thu, Feb 25, 2016 at 11:04:47PM +0100, Joachim Eastwood wrote:
>> Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
>> controller.
>>
>> Signed-off-by: Joa
On 2 March 2016 at 19:13, Rob Herring wrote:
> On Thu, Feb 25, 2016 at 11:04:47PM +0100, Joachim Eastwood wrote:
>> Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
>> controller.
>>
>> Signed-off-by: Joachim Eastwood
>> ---
>> ..
Hi Stephen,
On 1 March 2016 at 19:59, Stephen Boyd <sb...@codeaurora.org> wrote:
> This flag is a no-op now. Remove usage of the flag.
>
> Cc: Joachim Eastwood <manab...@gmail.com>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---
Acked-by: Joachim Eastwood <manab...@gmail.com>
Hi Stephen,
On 1 March 2016 at 19:59, Stephen Boyd wrote:
> This flag is a no-op now. Remove usage of the flag.
>
> Cc: Joachim Eastwood
> Signed-off-by: Stephen Boyd
> ---
Acked-by: Joachim Eastwood
Hi Thomas,
On 26 February 2016 at 11:26, Thomas Gleixner <t...@linutronix.de> wrote:
> On Thu, 25 Feb 2016, Joachim Eastwood wrote:
>> +static void lpc18xx_gpio_pint_handler(struct irq_desc *desc)
>> +{
>> + struct lpc18xx_gpio_pint_chip *pint = irq
Hi Thomas,
On 26 February 2016 at 11:26, Thomas Gleixner wrote:
> On Thu, 25 Feb 2016, Joachim Eastwood wrote:
>> +static void lpc18xx_gpio_pint_handler(struct irq_desc *desc)
>> +{
>> + struct lpc18xx_gpio_pint_chip *pint = irq_desc_get_handler_data(desc);
>
-clocks
> -mode selection MII or RMII.
>
> Signed-off-by: Alexandre TORGUE <alexandre.tor...@gmail.com>
Driver looks good now, thanks.
Reviewed-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
.
>
> Signed-off-by: Alexandre TORGUE
Driver looks good now, thanks.
Reviewed-by: Joachim Eastwood
regards,
Joachim Eastwood
interrupt-names = "macirq", "eth_wake_irq";
> + clock-names = "stmmaceth", "tx-clk", "rx-clk";
> + clocks = < 0 25>, < 0 26>, < 0 27>;
> + st,syscon = < 0x4>;
> + snps,pbl = <8>;
> + snps,mixed-burst;
> + dma-ranges;
> + };
Looks just like any other dwmac-driver binding so:
Acked-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
ake_irq";
> + clock-names = "stmmaceth", "tx-clk", "rx-clk";
> + clocks = < 0 25>, < 0 26>, < 0 27>;
> + st,syscon = < 0x4>;
> + snps,pbl = <8>;
> + snps,mixed-burst;
> + dma-ranges;
> + };
Looks just like any other dwmac-driver binding so:
Acked-by: Joachim Eastwood
regards,
Joachim Eastwood
trigger and supports
any polarity.
This patch set adds an irqchip driver for the PINT found on lpc18xx.
Joachim Eastwood (2):
irqchip: add lpc18xx gpio pin interrupt driver
devicetree: document NXP LPC1850 PINT irq controller binding
.../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 22
trigger and supports
any polarity.
This patch set adds an irqchip driver for the PINT found on lpc18xx.
Joachim Eastwood (2):
irqchip: add lpc18xx gpio pin interrupt driver
devicetree: document NXP LPC1850 PINT irq controller binding
.../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 22
Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
controller.
Signed-off-by: Joachim Eastwood <manab...@gmail.com>
---
.../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644
Documentation/devi
Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
controller.
Signed-off-by: Joachim Eastwood
---
.../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt
.
Selection of which GPIOs that are connected to the PINT is done by
the lpc18xx pinctrl driver (SCU).
Signed-off-by: Joachim Eastwood <manab...@gmail.com>
---
drivers/irqchip/Kconfig | 5 +
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-lpc18xx-gpio-pint.c
.
Selection of which GPIOs that are connected to the PINT is done by
the lpc18xx pinctrl driver (SCU).
Signed-off-by: Joachim Eastwood
---
drivers/irqchip/Kconfig | 5 +
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-lpc18xx-gpio-pint.c | 238
for (i = 0; i < ARRAY_SIZE(lpc18xx_pins); i++) {
> + for (func = 0; func < FUNC_MAX; func++) {
> + for (ngroups = 0, i = 0; i < ARRAY_SIZE(lpc18xx_pins); i++) {
Good catch!
Reviewed-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
= 0; func < FUNC_MAX; func++) {
> + for (ngroups = 0, i = 0; i < ARRAY_SIZE(lpc18xx_pins); i++) {
Good catch!
Reviewed-by: Joachim Eastwood
regards,
Joachim Eastwood
Hi Laxman,
On 24 February 2016 at 14:16, Laxman Dewangan <ldewan...@nvidia.com> wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
> Cc: Joachim Eastwood <manab...@gmail.com>
> ---
> d
Hi Laxman,
On 24 February 2016 at 14:16, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan
> Cc: Joachim Eastwood
> ---
> drivers/pinctrl/pinctrl-lpc18xx.c | 3 +--
> 1 file changed, 1 insertion(+),
interrupt-names = "macirq", "eth_wake_irq";
> + clock-names = "stmmaceth", "tx-clk", "rx-clk";
> + clocks = < 0 25>, < 0 26>, < 0 27>;
> + st,syscon = < 0x4>;
> + snps,pbl = <32>;
Regarding snps,pbl; using 32 here might not give you what you would except.
See comment in dwmac1000_dma_init().
The driver is hard coded to use PBL4X/PBL8X mode. Just a heads up.
regards,
Joachim Eastwood
_wake_irq";
> + clock-names = "stmmaceth", "tx-clk", "rx-clk";
> + clocks = < 0 25>, < 0 26>, < 0 27>;
> + st,syscon = < 0x4>;
> + snps,pbl = <32>;
Regarding snps,pbl; using 32 here might not give you what you would except.
See comment in dwmac1000_dma_init().
The driver is hard coded to use PBL4X/PBL8X mode. Just a heads up.
regards,
Joachim Eastwood
EP
> +static int stm32_dwmac_suspend(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + int ret;
> +
> + ret = stmmac_suspend(ndev);
> + stm32_dwmac_exit(priv->plat->bsp_priv);
> +
> + return ret;
> +}
> +
> +static int stm32_dwmac_resume(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + int ret;
> +
> + ret = stm32_dwmac_init(priv->plat->bsp_priv);
> + if (ret)
> + goto out_regmap;
> +
> + ret = stmmac_resume(ndev);
> +
> +out_regmap:
> + return ret;
Why the goto?
This could be written:
ret = stm32_dwmac_init(priv->plat->bsp_priv);
if (ret)
return ret;
return stmmac_resume(ndev);
regards,
Joachim Eastwood
+ struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + int ret;
> +
> + ret = stmmac_suspend(ndev);
> + stm32_dwmac_exit(priv->plat->bsp_priv);
> +
> + return ret;
> +}
> +
> +static int stm32_dwmac_resume(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + int ret;
> +
> + ret = stm32_dwmac_init(priv->plat->bsp_priv);
> + if (ret)
> + goto out_regmap;
> +
> + ret = stmmac_resume(ndev);
> +
> +out_regmap:
> + return ret;
Why the goto?
This could be written:
ret = stm32_dwmac_init(priv->plat->bsp_priv);
if (ret)
return ret;
return stmmac_resume(ndev);
regards,
Joachim Eastwood
On 23 February 2016 at 10:59, Alexandre Torgue
<alexandre.tor...@gmail.com> wrote:
> 2016-02-22 22:52 GMT+01:00 Joachim Eastwood <manab...@gmail.com>:
>> On 22 February 2016 at 15:50, Alexandre Torgue
>> <alexandre.tor...@gmail.com> wrote:
>>> 2016-02-1
On 23 February 2016 at 10:59, Alexandre Torgue
wrote:
> 2016-02-22 22:52 GMT+01:00 Joachim Eastwood :
>> On 22 February 2016 at 15:50, Alexandre Torgue
>> wrote:
>>> 2016-02-13 14:48 GMT+01:00 Joachim Eastwood :
>>>> On 3 February 2016 at
On 22 February 2016 at 03:29, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> Hi Joachim,
>
>
> 2016-02-22 6:39 GMT+09:00 Joachim Eastwood <manab...@gmail.com>:
>> Hi everyone,
>>
>> On 28 December 2015 at 11:10, Masahiro Yamada
>> <
On 22 February 2016 at 03:29, Masahiro Yamada
wrote:
> Hi Joachim,
>
>
> 2016-02-22 6:39 GMT+09:00 Joachim Eastwood :
>> Hi everyone,
>>
>> On 28 December 2015 at 11:10, Masahiro Yamada
>> wrote:
>>> Currently, clk_register() never checks a circular
On 22 February 2016 at 15:50, Alexandre Torgue
<alexandre.tor...@gmail.com> wrote:
> 2016-02-13 14:48 GMT+01:00 Joachim Eastwood <manab...@gmail.com>:
>> On 3 February 2016 at 15:54, Alexandre TORGUE
>> <alexandre.tor...@gmail.com> wrote:
>&
On 22 February 2016 at 15:50, Alexandre Torgue
wrote:
> 2016-02-13 14:48 GMT+01:00 Joachim Eastwood :
>> On 3 February 2016 at 15:54, Alexandre TORGUE
>> wrote:
>>> + plat_dat->bsp_priv = dwmac;
>>> + plat_dat->init = stm32_dwmac_init;
>&g
ure on:
https://github.com/manabian/linux-lpc/wiki/LPC18xx-LPC43xx-clocks
All PLLs can feed clock into the dividers and the dividers can feed
clock into the PLLs.
The reason why this is made possible in the CGU is because you can
then choose where to put your divider; either before the PLL or after.
regards,
Joachim Eastwood
/manabian/linux-lpc/wiki/LPC18xx-LPC43xx-clocks
All PLLs can feed clock into the dividers and the dividers can feed
clock into the PLLs.
The reason why this is made possible in the CGU is because you can
then choose where to put your divider; either before the PLL or after.
regards,
Joachim Eastwood
On 17 February 2016 at 23:11, Andrew Lunn <and...@lunn.ch> wrote:
> On Wed, Feb 17, 2016 at 11:02:56PM +0100, Joachim Eastwood wrote:
>> Hi Andrew,
>>
>> On 17 February 2016 at 21:07, Andrew Lunn <and...@lunn.ch> wrote:
>> > Add a reg
On 17 February 2016 at 23:11, Andrew Lunn wrote:
> On Wed, Feb 17, 2016 at 11:02:56PM +0100, Joachim Eastwood wrote:
>> Hi Andrew,
>>
>> On 17 February 2016 at 21:07, Andrew Lunn wrote:
>> > Add a regmap for accessing the EEPROM, and then use that with the
>>
On 17 February 2016 at 23:02, Joachim Eastwood <manab...@gmail.com> wrote:
> Hi Andrew,
>
> On 17 February 2016 at 21:07, Andrew Lunn <and...@lunn.ch> wrote:
>> +/*
>> + * Provide a regmap interface, which is registered with the NVMEM
>&
On 17 February 2016 at 23:02, Joachim Eastwood wrote:
> Hi Andrew,
>
> On 17 February 2016 at 21:07, Andrew Lunn wrote:
>> +/*
>> + * Provide a regmap interface, which is registered with the NVMEM
>> + * framework
>> +*/
>> +static int eeprom_93xx46_reg
*context, const void *data,
> + size_t count)
> +{
> + struct eeprom_93xx46_dev *eeprom_93xx46 = context;
> + const char *buf;
> + u32 offset;
> + size_t len;
> + int err;
> +
> + memcpy(, data, sizeof(offset));
> + buf = (const char *)data + sizeof(offset);
> + len = count - sizeof(offset);
> +
> + err = eeprom_93xx46_write(eeprom_93xx46, buf, offset, len);
> + if (err)
> + return err;
> + return 0;
Same here.
regards,
Joachim Eastwood
turn err;
> + return 0;
Can be:
return eeprom_93xx46_read(eeprom_93xx46, val, offset, val_size);
Allows you to remove the 'err' variable also.
> +}
> +
> +static int eeprom_93xx46_regmap_write(void *context, const void *data,
> + size_t count)
> +{
> + struct eeprom_93xx46_dev *eeprom_93xx46 = context;
> + const char *buf;
> + u32 offset;
> + size_t len;
> + int err;
> +
> + memcpy(, data, sizeof(offset));
> + buf = (const char *)data + sizeof(offset);
> + len = count - sizeof(offset);
> +
> + err = eeprom_93xx46_write(eeprom_93xx46, buf, offset, len);
> + if (err)
> + return err;
> + return 0;
Same here.
regards,
Joachim Eastwood
uot;},
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
> +
> +static struct platform_driver stm32_dwmac_driver = {
> + .probe = stm32_dwmac_probe,
> + .remove = stmmac_pltfr_remove,
Could you implement the .remove callback in your driver instead of
using stmmac_pltfr_remove?
Same reasons as above.
> + .driver = {
> + .name = "stm32-dwmac",
> + .pm = _pltfr_pm_ops,
> + .of_match_table = stm32_dwmac_match,
> + },
> +};
> +module_platform_driver(stm32_dwmac_driver);
> +
> +MODULE_AUTHOR("Alexandre Torgue ");
> +MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
> +MODULE_LICENSE("GPL");
Since you state:
> + * License terms: GNU General Public License (GPL), version 2
You might want to switch use: MODULE_LICENSE("GPL v2");
regards,
Joachim Eastwood
ruct of_device_id stm32_dwmac_match[] = {
> + { .compatible = "st,stm32-dwmac"},
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
> +
> +static struct platform_driver stm32_dwmac_driver = {
> + .probe = stm32_dwmac_probe,
> + .remove = stmmac_pltfr_remove,
Could you implement the .remove callback in your driver instead of
using stmmac_pltfr_remove?
Same reasons as above.
> + .driver = {
> + .name = "stm32-dwmac",
> + .pm = _pltfr_pm_ops,
> + .of_match_table = stm32_dwmac_match,
> + },
> +};
> +module_platform_driver(stm32_dwmac_driver);
> +
> +MODULE_AUTHOR("Alexandre Torgue <alexandre.tor...@gmail.com>");
> +MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
> +MODULE_LICENSE("GPL");
Since you state:
> + * License terms: GNU General Public License (GPL), version 2
You might want to switch use: MODULE_LICENSE("GPL v2");
regards,
Joachim Eastwood
1 - 100 of 182 matches
Mail list logo
