series a quick spin on RM9200 as well and the
at91_ether driver still works. Not many patches here that touch the
shared code though.
So FWIW;
Tested-by: Joachim Eastwood manab...@gmail.com
Note: Needed the patch you sent out (net/at91_ether: fix the use of
macb structure) to fix the build error
);
+ }
+
err = -ENOMEM;
dev = alloc_etherdev(sizeof(*bp));
if (!dev)
--
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
a custom board with AT91RM9200 and 1 USB host port.
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
: -17
[ 16.18] mpa1600-audio: probe of mpa1600-audio.0 failed with error -17
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
+#include linux/of_net.h
+#include linux/pinctrl/consumer.h
+ #include linux/platform_data/atmel.h
The platform_data/atmel.h include shouldn't be necessary since the
driver already includes platform_data/macb.h.
Otherwise the fix up looks correct.
regards
Joachim Eastwood
--
To unsubscribe from
://patchwork.kernel.org/patch/2165301/
Can't find the patch in any upstream git tree so I guess Grant hasn't
pushed it yet.
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
(pinctrl);
+ }
+
This patch should be dropped since driver core will now do this for us.
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Acked-by: Joachim Eastwood manab...@gmail.com
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
the two struct members alone, for now, or fix
up at91_ether at the same time.
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Everything we need from param.h on AVR32 is already in
asm-generic so let's use that.
Signed-off-by: Joachim Eastwood manab...@gmail.com
---
arch/avr32/include/asm/Kbuild | 1 +
arch/avr32/include/asm/param.h | 9 -
2 files changed, 1 insertion(+), 9 deletions(-)
delete mode 100644 arch
(OMAP4460) board.
Tested-by: Joachim Eastwood manab...@gmail.com
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
*/
+ OMAP3630_CORE2_IOPAD(0x25e4, PIN_INPUT | MUX_MODE4)
/* rx */
;
};
};
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On 16 July 2014 09:17, Dr. H. Nikolaus Schaller h...@goldelico.com wrote:
Am 15.07.2014 um 14:45 schrieb Joachim Eastwood:
Hi Marek,
You seem to add some DT nodes for hw that doesn't have drivers in
mainline. I think you should leave those out until the driver itself
is upstream
On 26 September 2014 06:56, Pankaj Dubey pankaj.du...@samsung.com wrote:
Hi Heiko and Joachim,
-Original Message-
From: Heiko Stübner [mailto:he...@sntech.de]
Sent: Thursday, September 25, 2014 5:52 PM
To: Pankaj Dubey
Cc: Joachim Eastwood; linux-arm-ker...@lists.infradead.org
On 26 September 2014 09:16, Arnd Bergmann a...@arndb.de wrote:
On Friday 26 September 2014 07:34:12 Joachim Eastwood wrote:
I am working on Cortex-M4 no-MMU platform that isn't upstream yet, btw.
Sorry for drifting off-topic, but this is very interesting to me. Can you
say which one you
On 14 September 2014 21:47, Al Viro v...@zeniv.linux.org.uk wrote:
double iput() on failure exit in lustre, racy removal of spliced dentries
from -s_anon in __d_materialise_dentry() plus a bunch of assorted RCU
pathwalk
fixes. Please, pull from the usual place -
) readonly on device 1:0.
[ 9.60] devtmpfs: mounted
[ 9.61] Freeing unused kernel memory: 68K (281e5000 - 281f6000)
And then user space starts.
This is an ARM Cortex-M4 no-MMU platform that is not yet upstream.
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line
On 26 September 2014 22:58, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Sep 26, 2014 at 10:46:14PM +0200, Joachim Eastwood wrote:
On 14 September 2014 21:47, Al Viro v...@zeniv.linux.org.uk wrote:
double iput() on failure exit in lustre, racy removal of spliced dentries
from -s_anon
On 26 September 2014 23:28, Joachim Eastwood manab...@gmail.com wrote:
On 26 September 2014 22:58, Al Viro v...@zeniv.linux.org.uk wrote:
On Fri, Sep 26, 2014 at 10:46:14PM +0200, Joachim Eastwood wrote:
On 14 September 2014 21:47, Al Viro v...@zeniv.linux.org.uk wrote:
double iput
driver using syscon and your patch. clk driver uses
CLK_OF_DECLARE, btw.
It works but I get a '(null): Failed to create debugfs directory'
message in the boot log.
Tested-by: Joachim Eastwood manab...@gmail.com
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe
on OF (ARCH_LPC18XX || COMPILE_TEST)
Is there a patch queued somewhere to add ARCH_LPC18XX ?
Currently it's only on the mail list.
See: http://marc.info/?l=linux-arm-kernelm=143016894704253w=2
Some drivers are going upstream before the base support.
regards,
Joachim Eastwood
I detected
);
+ clk_put(priv-clk);
+ }
If you use devm_clk_get() in uniphier_of_serial_setup() you only need
to call clk_disable_unprepare() here.
Calling clk_disable_unprepare() with NULL is allowed and you already
check for IS_ERR in your setup function.
+ return 0;
+}
regards,
Joachim
two platforms as a follow-up.
Thanks for fixing up LPC18xx as well.
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
.
Since next didn't build for me either I applied this and it works for
the LPC18xx (Cortex-M4) platform.
Tested-by: Joachim Eastwood manab...@gmail.com
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
-by: Matthias Brugger matthias@gmail.com
I think it looks fine now and I have no further comments, so:
Acked-by: Joachim Eastwood manab...@gmail.com
Hope this can go in for 4.3.
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read
;
+ int rc;
rc = osc_flush_async_page(env, io, opg);
return rc;
The whole rc variable is kinda useless.
Why not make it just:
return osc_flush_async_page(env, io, opg);
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please
.
Hope some clk maintainer will have the time to look at it soon also.
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
iomem and regmap at the same time.
Could this be put in a union or does that make registration more
difficult?
u32 *table;
+ u32 offset;
u32 mask;
u8 shift;
u8 flags;
regards,
Joachim
be changed */
#define CLK_MUX_ROUND_CLOSEST BIT(4)
+#define CLK_MUX_USE_REGMAP BIT(5)
Since you are adding both fields and a flag to struct clk_mux it would
be nice if you could update the documentation above the struct
definition in clk-provider.h also.
regards,
Joachim Eastwood
);
+ kfree(soc_dev_attr);
With devm_* you can remove this stuff.
+ }
+
+ if (soc_dev)
+ soc_device_unregister(soc_dev);
+
+ return 0;
+}
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
CLKSRC_LPC32XX
+ select PINCTRL
+ help
+ Support for NXP's LPC18xx Cortex-M3 and LPC43xx Cortex-M4
+ high performance microcontrollers.
The LPC18xx parts look good and it still builds and boots on my devkit so;
Acked-by: Joachim Eastwood manab...@gmail.com
regards,
Joachim
Hi Stefan.
On 21 May 2015 at 00:38, Stefan Agner ste...@agner.ch wrote:
Select ARM_SINGLE_ARMV7M in defconfigs of the converted ARMv7-M
platforms.
Signed-off-by: Stefan Agner ste...@agner.ch
For the LPC18xx config;
Acked-by: Joachim Eastwood manab...@gmail.com
regards,
Joachim Eastwood
orphaned.
Suggested-by: Joachim Eastwood manab...@gmail.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.com
Cc: Joachim Eastwood manab...@gmail.com
Cc: linux-ser...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Paul Gortmaker paul.gortma
) 27) 0x01;
I'll try to get this patch tested on my lpc18xx platform soon.
btw, the HCON reg on lpc18xx reads as 0x00e42cc1 (address 0x40004070).
regard,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
-chips.com
Acked-by: Joachim Eastwood manab...@gmail.com
arch/arm/configs/lpc18xx_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/lpc18xx_defconfig
b/arch/arm/configs/lpc18xx_defconfig
index 1c47f86..b7e8cda 100644
--- a/arch/arm/configs/lpc18xx_defconfig
+++ b/arch
if I can find the time to test your patch set. Thanks for
working on this.
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
and it builds
just fine with 'm'.
Want me send a patch changing it to tristate or will you handle it?
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
_caps *)
> - of_match_device(atmel_nand_dt_ids, host->dev)->data;
> + of_id = of_match_device(atmel_nand_dt_ids, host->dev);
> + if (!of_id)
> + return -ENODEV;
> + host->caps = of_id->data;
It might be cleaner to use of_device_get_match
18XX_PWM_EVSTATEMSK_ALL);
>
> - if (pwm->polarity == PWM_POLARITY_NORMAL) {
> + if (pwm_get_polarity((pwm)) == PWM_POLARITY_NORMAL) {
What is the deal with the double parentheses?
Think I saw that in some of the other patches as well.
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 11 July 2015 at 01:33, Stephen Boyd sb...@codeaurora.org wrote:
Clock provider drivers generally shouldn't include clk.h because
it's the consumer API. Remove the include here because this is a
provider driver.
Cc: Joachim Eastwood manab...@gmail.com
Signed-off-by: Stephen Boyd sb
u_reset,
> .assert = lpc18xx_rgu_assert,
> .deassert = lpc18xx_rgu_deassert,
Acked-by: Joachim Eastwood <manab...@gmail.com>
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
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
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
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 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:
>&
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
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
.
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
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
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
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
>> <
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
-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
*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
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: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
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
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>
7455)
> {
> + struct device *dev = regmap_get_device(mma7455->regmap);
ah, nice!
Acked-by: Joachim Eastwood <manab...@gmail.com>
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
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
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
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
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
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
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
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
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
> + 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
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
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
end
> it. Often reviewers don't get enough credit in my opinion!
Sure;
Reviewed-by: Joachim Eastwood <manab...@gmail.com>
regards,
Joachim Eastwood
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
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
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
ext.com>
> ---
Acked-by: Joachim Eastwood <manab...@gmail.com>
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
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
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
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
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 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
).
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
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
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
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
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
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
EM, 0);
> if (!regs)
> return -ENXIO;
>
> + pinctrl = devm_pinctrl_get_select_default(>dev);
> + if (IS_ERR(pinctrl)) {
> + dev_err(>dev, "Failed to request pinctrl\n");
> + return PTR_ERR(pinctr
}
I sent a similar patch to spi-devl a while ago, which Grant said he applied.
https://patchwork.kernel.org/patch/2165301/
Can't find the patch in any upstream git tree so I guess Grant hasn't
pushed it yet.
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line "un
pins {
> + pinctrl-single,pins = <
> + OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
> /* etk_d10.hsusb2_clk */
> + OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
> /* etk_d11.hsusb2
On 16 July 2014 09:17, Dr. H. Nikolaus Schaller wrote:
> Am 15.07.2014 um 14:45 schrieb Joachim Eastwood:
>
>> Hi Marek,
>>
>> You seem to add some DT nodes for hw that doesn't have drivers in
>> mainline. I think you should leave those out until the driver itself
&
s.
Gave the patch series a quick spin on RM9200 as well and the
at91_ether driver still works. Not many patches here that touch the
shared code though.
So FWIW;
Tested-by: Joachim Eastwood
Note: Needed the patch you sent out (net/at91_ether: fix the use of
macb structure) to fix the build err
>
> + pinctrl = devm_pinctrl_get_select_default(>dev);
> + if (IS_ERR(pinctrl)) {
> + err = PTR_ERR(pinctrl);
> + if (err == -EPROBE_DEFER)
> + goto err_out;
> +
> + dev_warn(>dev,
number 1
[8.34] at91_ohci at91_ohci: irq 39, io mem 0x0030
[8.52] hub 1-0:1.0: USB hub found
[8.66] hub 1-0:1.0: 1 port detected
I assume this commit tried to fix the "can't request overcurrent gpio
0" message.
I am running a custom board with AT91RM9200
On 23 November 2012 14:49, Nicolas Ferre wrote:
> Add information to the DMA Configuration Register to
> maximize system performance:
> - rx/tx packet buffer full memory size
> - allow possibility to use INCR16 if supported
>
> Signed-off-by: Nicolas Ferre
Acked-by: Joa
> --
struct macb is shared between at91_ether and macb. Removing
rx_buffers_dma and rx_buffers will break compilation on at91_ether.
So please either leave the two struct members alone, for now, or fix
up at91_ether at the same time.
regards
Joachim Eastwood
--
To unsubscribe from this list: s
1 - 100 of 182 matches
Mail list logo
