* Re: [PATCH v6 net-next,mips 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.
From: David Miller @ 2017-12-08 19:29 UTC (permalink / raw)
To: david.daney-YGCgFSpz5w/QT0dZR+AlfA
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA, ralf-6z/3iImG2C8G8FEW9MqTrA,
james.hogan-8NJIiSa5LzA, netdev-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
steven.hill-YGCgFSpz5w/QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, pombredanne-od1rfyK75/E,
cmunoz-YGCgFSpz5w/QT0dZR+AlfA
In-Reply-To: <20171208000934.6554-7-david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
From: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Date: Thu, 7 Dec 2017 16:09:33 -0800
> +static void bgx_port_check_state(struct work_struct *work)
> +{
...
> + mutex_lock(&priv->lock);
> + if (priv->work_queued)
> + queue_delayed_work(check_state_wq, &priv->dwork, HZ);
> + mutex_unlock(&priv->lock);
> +}
...
> +int bgx_port_disable(struct net_device *netdev)
> +{
...
> + mutex_lock(&priv->lock);
> + if (priv->work_queued) {
> + cancel_delayed_work_sync(&priv->dwork);
> + priv->work_queued = false;
This can deadlock.
When you do a sync work cancel, it waits until all running work
instances finish. You have the priv->lock, so if
bgx_port_check_status() need to still take priv->lock to complete
then no further progress will be made.
I think it is pointless to use this weird work_queued boolean state.
Just unconditionally, and without locking, cancel the delayed work,
ragardless of whether it was actually used ever or not.
Thank you.
--
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 1/3] Bluetooth: hci_ll: add support for setting public address
From: Marcel Holtmann @ 2017-12-08 19:24 UTC (permalink / raw)
To: David Lechner
Cc: devicetree, open list:BLUETOOTH DRIVERS, Rob Herring,
Mark Rutland, Gustavo F. Padovan, Johan Hedberg,
Network Development, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1a106ed6-1408-4d0b-9c9d-5a3058d6df2d-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Hi David,
>>> This adds support for setting the public address on Texas Instruments
>>> Bluetooth chips using a vendor-specific command.
>>>
>>> This has been tested on a CC2560A. The TI wiki also indicates that this
>>> command should work on TI WL17xx/WL18xx Bluetooth chips.
>>>
>>> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
>>> ---
>>>
>>> v2 changes:
>>> * This is a new patch in v2
>>>
>>> drivers/bluetooth/hci_ll.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
>>> index 974a788..b732004 100644
>>> --- a/drivers/bluetooth/hci_ll.c
>>> +++ b/drivers/bluetooth/hci_ll.c
>>> @@ -57,6 +57,7 @@
>>> #include "hci_uart.h"
>>>
>>> /* Vendor-specific HCI commands */
>>> +#define HCI_VS_WRITE_BD_ADDR 0xfc06
>>> #define HCI_VS_UPDATE_UART_HCI_BAUDRATE 0xff36
>>>
>>> /* HCILL commands */
>>> @@ -662,6 +663,20 @@ static int download_firmware(struct ll_device *lldev)
>>> return err;
>>> }
>>>
>>> +static int ll_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr)
>>> +{
>>> + bdaddr_t bdaddr_swapped;
>>> + struct sk_buff *skb;
>>> +
>>> + baswap(&bdaddr_swapped, bdaddr);
>>> + skb = __hci_cmd_sync(hdev, HCI_VS_WRITE_BD_ADDR, sizeof(bdaddr_t),
>>> + &bdaddr_swapped, HCI_INIT_TIMEOUT);
>>> + if (!IS_ERR(skb))
>>> + kfree_skb(skb);
>>> +
>> You have a trailing whitespace here.
>> Does the HCI command really expect the BD_ADDR in the swapped order. The caller of hdev->set_bdaddr while provide it in the same order as the HCI Read BD Address command and everything in HCI. So it seems odd that you have to swap it for the vendor command.
>> So have you actually tested this with btmgmt public-add <xx:xx..> and checked that the address comes out correctly. I think ll_set_bdaddr should function correctly for the mgmt interface. And if needed any other caller outside of mgmt has to do the swapping.
>
> I did test using btmgmt public-address 00:11:22:33:44:55, which is how I found out that the order needed to be swapped. Like you, I was surprised. I couldn't find any documentation from TI saying what the order is supposed to be, so I can only assume that because this works, it is indeed correct as-is.
then please add a comment for that and I would appreciate to have the parts from btmon showing the public-addr command and the following HCI Read BD Address command as part of the commit message. Just for being able to dig this out at some later point if needed.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2 1/3] Bluetooth: hci_ll: add support for setting public address
From: David Lechner @ 2017-12-08 19:21 UTC (permalink / raw)
To: Marcel Holtmann
Cc: devicetree, open list:BLUETOOTH DRIVERS, Rob Herring,
Mark Rutland, Gustavo F. Padovan, Johan Hedberg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8B6C3CFA-35C6-4A9B-90AB-22834B9AE2C4-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On 12/08/2017 02:07 AM, Marcel Holtmann wrote:
> Hi David,
>
>> This adds support for setting the public address on Texas Instruments
>> Bluetooth chips using a vendor-specific command.
>>
>> This has been tested on a CC2560A. The TI wiki also indicates that this
>> command should work on TI WL17xx/WL18xx Bluetooth chips.
>>
>> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
>> ---
>>
>> v2 changes:
>> * This is a new patch in v2
>>
>> drivers/bluetooth/hci_ll.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
>> index 974a788..b732004 100644
>> --- a/drivers/bluetooth/hci_ll.c
>> +++ b/drivers/bluetooth/hci_ll.c
>> @@ -57,6 +57,7 @@
>> #include "hci_uart.h"
>>
>> /* Vendor-specific HCI commands */
>> +#define HCI_VS_WRITE_BD_ADDR 0xfc06
>> #define HCI_VS_UPDATE_UART_HCI_BAUDRATE 0xff36
>>
>> /* HCILL commands */
>> @@ -662,6 +663,20 @@ static int download_firmware(struct ll_device *lldev)
>> return err;
>> }
>>
>> +static int ll_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr)
>> +{
>> + bdaddr_t bdaddr_swapped;
>> + struct sk_buff *skb;
>> +
>> + baswap(&bdaddr_swapped, bdaddr);
>> + skb = __hci_cmd_sync(hdev, HCI_VS_WRITE_BD_ADDR, sizeof(bdaddr_t),
>> + &bdaddr_swapped, HCI_INIT_TIMEOUT);
>> + if (!IS_ERR(skb))
>> + kfree_skb(skb);
>> +
>
> You have a trailing whitespace here.
>
> Does the HCI command really expect the BD_ADDR in the swapped order. The caller of hdev->set_bdaddr while provide it in the same order as the HCI Read BD Address command and everything in HCI. So it seems odd that you have to swap it for the vendor command.
>
> So have you actually tested this with btmgmt public-add <xx:xx..> and checked that the address comes out correctly. I think ll_set_bdaddr should function correctly for the mgmt interface. And if needed any other caller outside of mgmt has to do the swapping.
>
I did test using btmgmt public-address 00:11:22:33:44:55, which is how I
found out that the order needed to be swapped. Like you, I was
surprised. I couldn't find any documentation from TI saying what the
order is supposed to be, so I can only assume that because this works,
it is indeed correct as-is.
--
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] ARM64: dts: meson-gxm: fix q200 interrupt number
From: Kevin Hilman @ 2017-12-08 18:49 UTC (permalink / raw)
To: Jerome Brunet
Cc: Martin Blumenstingl,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171204100504.7741-1-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> Correct the interrupt number assigned to the Realtek PHY in the q200
>
> Fixes: b94d22d94ad2 ("ARM64: dts: meson-gx: add external PHY interrupt on some platforms")
> Reported-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>
> This change depends on the related series from Martin [0]
> Thanks for catching it Martin !
Applied to v4.16/dt64 on top of Martin's series.
> [0]: https://lkml.kernel.org/r/20171202214037.17017-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
FYI: This results in: No such Message-ID known.
Kevin
--
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 4/4] PCI: dwc: pci-dra7xx: Fix legacy IRQ handling
From: Lorenzo Pieralisi @ 2017-12-08 18:35 UTC (permalink / raw)
To: Vignesh R
Cc: Bjorn Helgaas, Rob Herring, Tony Lindgren, Chris Welch,
Kishon Vijay Abraham I, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171201061311.16691-5-vigneshr-l0cyMroinI0@public.gmane.org>
On Fri, Dec 01, 2017 at 11:43:11AM +0530, Vignesh R wrote:
> Legacy INTD IRQ handling is broken on dra7xx due to fact that driver
> uses hwirq in range of 1-4 for INTA, INTD whereas IRQ domain is of size
> 4 which is numbered 0-3. Therefore when INTD IRQ line is used with
> pci-dra7xx driver following warning is seen:
>
> WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:342 irq_domain_associate+0x12c/0x1c4
> error: hwirq 0x4 is too large for dummy
>
> Fix this by using pci_irqd_intx_xlate() helper to translate the INTx 1-4
> range into the 0-3 as done in other PCIe drivers.
>
> Also, iterate over all the INTx bits and call their respective IRQ
> handlers before clearing the status register.
It seems to me that you are fixing two bugs with one patch and therefore
I would ask you to split it in two or explain to me why we should
consider lumping them together.
Thanks,
Lorenzo
> Suggested-by: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Reported-by: Chris Welch <Chris.Welch-ojoHHoaXhABCkLs28/y7ANBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
> ---
> drivers/pci/dwc/pci-dra7xx.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index 53f721d1cc40..59e8de34cec6 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -226,6 +226,7 @@ static int dra7xx_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
>
> static const struct irq_domain_ops intx_domain_ops = {
> .map = dra7xx_pcie_intx_map,
> + .xlate = pci_irqd_intx_xlate,
> };
>
> static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
> @@ -256,7 +257,8 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, void *arg)
> struct dra7xx_pcie *dra7xx = arg;
> struct dw_pcie *pci = dra7xx->pci;
> struct pcie_port *pp = &pci->pp;
> - u32 reg;
> + unsigned long reg;
> + u32 virq, bit;
>
> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>
> @@ -268,8 +270,11 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, void *arg)
> case INTB:
> case INTC:
> case INTD:
> - generic_handle_irq(irq_find_mapping(dra7xx->irq_domain,
> - ffs(reg)));
> + for_each_set_bit(bit, ®, PCI_NUM_INTX) {
> + virq = irq_find_mapping(dra7xx->irq_domain, bit);
> + if (virq)
> + generic_handle_irq(virq);
> + }
> break;
> }
>
> --
> 2.15.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 RESEND v7 1/2] at24: support eeproms that do not auto-rollover reads.
From: Bartosz Golaszewski @ 2017-12-08 17:22 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: Rob Herring, Mark Rutland, Wolfram Sang, nsekhar, Sakari Ailus,
David Lechner, Javier Martinez Canillas, Divagar Mohandass,
devicetree, Linux Kernel Mailing List, linux-i2c
In-Reply-To: <1512750511-24505-2-git-send-email-svendev@arcx.com>
2017-12-08 17:28 GMT+01:00 Sven Van Asbroeck <svendev@arcx.com>:
> Some multi-address eeproms in the at24 family may not automatically
> roll-over reads to the next slave address. On those eeproms, reads
> that straddle slave boundaries will not work correctly.
>
> Solution:
> Mark such eeproms with a flag that prevents reads straddling
> slave boundaries. Add the AT24_FLAG_NO_RDROL flag to the eeprom
> entry in the device_id table, or add 'no-read-rollover' to the
> eeprom devicetree entry.
>
> Note that I have not personally enountered an at24 chip that
> does not support read rollovers. They may or may not exist.
> However, my hardware requires this functionality because of
> a quirk.
>
> It's up to the Linux community to decide if this patch is useful/
> general enough to warrant merging.
>
> Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
> ---
> drivers/misc/eeprom/at24.c | 39 ++++++++++++++++++++++++++------------
> include/linux/platform_data/at24.h | 2 ++
> 2 files changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 625b001..06ffa11 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -251,15 +251,6 @@ struct at24_data {
> * Slave address and byte offset derive from the offset. Always
> * set the byte address; on a multi-master board, another master
> * may have changed the chip's "current" address pointer.
> - *
> - * REVISIT some multi-address chips don't rollover page reads to
> - * the next slave address, so we may need to truncate the count.
> - * Those chips might need another quirk flag.
> - *
> - * If the real hardware used four adjacent 24c02 chips and that
> - * were misconfigured as one 24c08, that would be a similar effect:
> - * one "eeprom" file not four, but larger reads would fail when
> - * they crossed certain pages.
> */
> static struct at24_client *at24_translate_offset(struct at24_data *at24,
> unsigned int *offset)
> @@ -277,6 +268,30 @@ static struct at24_client *at24_translate_offset(struct at24_data *at24,
> return &at24->client[i];
> }
>
> +static size_t at24_adjust_read_count(struct at24_data *at24,
> + unsigned int offset, size_t count)
> +{
> + unsigned int bits;
> + size_t remainder;
> +
> + /*
> + * In case of multi-address chips that don't rollover reads to
> + * the next slave address: truncate the count to the slave boundary,
> + * so that the read never straddles slaves.
> + */
> + if (at24->chip.flags & AT24_FLAG_NO_RDROL) {
> + bits = (at24->chip.flags & AT24_FLAG_ADDR16) ? 16 : 8;
> + remainder = BIT(bits) - offset;
> + if (count > remainder)
> + count = remainder;
> + }
> +
> + if (count > io_limit)
> + count = io_limit;
> +
> + return count;
> +}
> +
> static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
> unsigned int offset, size_t count)
> {
> @@ -289,9 +304,7 @@ static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
> at24_client = at24_translate_offset(at24, &offset);
> regmap = at24_client->regmap;
> client = at24_client->client;
> -
> - if (count > io_limit)
> - count = io_limit;
> + count = at24_adjust_read_count(at24, offset, count);
>
> /* adjust offset for mac and serial read ops */
> offset += at24->offset_adj;
> @@ -457,6 +470,8 @@ static void at24_get_pdata(struct device *dev, struct at24_platform_data *chip)
>
> if (device_property_present(dev, "read-only"))
> chip->flags |= AT24_FLAG_READONLY;
> + if (device_property_present(dev, "no-read-rollover"))
> + chip->flags |= AT24_FLAG_NO_RDROL;
>
> err = device_property_read_u32(dev, "size", &val);
> if (!err)
> diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
> index 271a4e2..841bb28 100644
> --- a/include/linux/platform_data/at24.h
> +++ b/include/linux/platform_data/at24.h
> @@ -50,6 +50,8 @@ struct at24_platform_data {
> #define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */
> #define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */
> #define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */
> +#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */
> + /* the next slave address */
>
> void (*setup)(struct nvmem_device *nvmem, void *context);
> void *context;
> --
> 1.9.1
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v7 2/2] dt-bindings: add eeprom "no-read-rollover" property
From: Bartosz Golaszewski @ 2017-12-08 17:22 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: Rob Herring, Mark Rutland, Wolfram Sang, nsekhar-l0cyMroinI0,
Sakari Ailus, David Lechner, Javier Martinez Canillas,
Divagar Mohandass, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, linux-i2c
In-Reply-To: <1512750511-24505-3-git-send-email-svendev-fuHqz3Nb1YI@public.gmane.org>
2017-12-08 17:28 GMT+01:00 Sven Van Asbroeck <svendev-fuHqz3Nb1YI@public.gmane.org>:
> Adds an optional property for at24 eeproms.
> This parameterless property indicates that the multi-address eeprom
> does not automatically roll over reads to the next slave address.
>
> Signed-off-by: Sven Van Asbroeck <svendev-fuHqz3Nb1YI@public.gmane.org>
> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/eeprom/at24.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
> index 27f2bc1..a0415b8 100644
> --- a/Documentation/devicetree/bindings/eeprom/at24.txt
> +++ b/Documentation/devicetree/bindings/eeprom/at24.txt
> @@ -38,6 +38,11 @@ Optional properties:
>
> - size: total eeprom size in bytes
>
> + - no-read-rollover:
> + This parameterless property indicates that the multi-address
> + eeprom does not automatically roll over reads to the next
> + slave address. Please consult the manual of your device.
> +
> Example:
>
> eeprom@52 {
> --
> 1.9.1
>
Applied, thanks!
--
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 v4.1] phylib: Add device reset GPIO support
From: Sergei Shtylyov @ 2017-12-08 17:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, David S . Miller, Andrew Lunn,
Florian Fainelli, Simon Horman, Magnus Damm, Rob Herring,
Mark Rutland, Nicolas Ferre, Richard Leitner,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdWv6CiCihjFHn-k2=3PC+-bRQaKMsZcsx51MYpynTLO4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello!
On 12/08/2017 12:53 PM, Geert Uytterhoeven wrote:
>> On 12/04/2017 03:35 PM, Geert Uytterhoeven wrote:
>>> From: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>>> The PHY devices sometimes do have their reset signal (maybe even power
>>> supply?) tied to some GPIO and sometimes it also does happen that a boot
>>> loader does not leave it deasserted. So far this issue has been attacked
>>> from (as I believe) a wrong angle: by teaching the MAC driver to
>>> manipulate
>>> the GPIO in question; that solution, when applied to the device trees, led
>>> to adding the PHY reset GPIO properties to the MAC device node, with one
>>> exception: Cadence MACB driver which could handle the "reset-gpios" prop
>>> in a PHY device subnode. I believe that the correct approach is to teach
>>> the 'phylib' to get the MDIO device reset GPIO from the device tree node
>>> corresponding to this device -- which this patch is doing...
>>>
>>> Note that I had to modify the AT803x PHY driver as it would stop working
>>> otherwise -- it made use of the reset GPIO for its own purposes...
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> [geert: Propagate actual errors from fwnode_get_named_gpiod()]
>>> [geert: Avoid destroying initial setup]
>>> [geert: Consolidate GPIO descriptor acquiring code]
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>>
>> [...]
>>>
>>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>>> index 2df7b62c1a36811e..8f8b7747c54bc478 100644
>>> --- a/drivers/net/phy/mdio_bus.c
>>> +++ b/drivers/net/phy/mdio_bus.c
>>
>> [...]
>>>
>>> @@ -48,9 +49,26 @@
>>> int mdiobus_register_device(struct mdio_device *mdiodev)
>>> {
>>> + struct gpio_desc *gpiod = NULL;
>>> +
>>> if (mdiodev->bus->mdio_map[mdiodev->addr])
>>> return -EBUSY;
>>> + /* Deassert the optional reset signal */
>>
>>
>> Umm, but why deassert it here for such a short time?
>
> That's a consequence of moving it from drivers/of/of_mdio.c to here.
Well, you shouldn't do code moves without some thinking. ;-)
> Not that it was deasserted that much longer in drivers/of/of_mdio.c, though...
There it had a reason, here I'm not seeing one. Perhaps using GPIOD_ASIS
(or GPIOD_OUT_HIGH) instead of GPIOD_OUT_LOW and dropping
mdio_device_reset(mdiodev, 1) afterwards would make more sense here?
> Gr{oetje,eeting}s,
>
> Geert
MBR, Sergei
--
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 v4.14] Add support for bq27521 battery monitor
From: Sebastian Reichel @ 2017-12-08 17:06 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Pavel Machek, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w, kernel list,
linux-arm-kernel, linux-omap-u79uwXL29TY76Z2rM5mHXA,
tony-4v6yS6AI5VpBDgjK7y7TUQ, khilman-DgEjT+Ai2ygdnm+yROfE0A,
aaro.koskinen-X3B1VOXEql0,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
patrikbachan-Re5JQEeQqe8AvxtiuMwx3w, serge-A9i7LUbDfNHQT0dZR+AlfA,
abcloriens-Re5JQEeQqe8AvxtiuMwx3w, clayton-fehKsxFhGzZIf6P1QZMOBw,
martijn-28JJ9oSIdodmR6Xm/wNWPw,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <cfa89227-e08a-849f-c886-723268ae657c-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]
Hi,
On Mon, Dec 04, 2017 at 09:20:33AM -0600, Andrew F. Davis wrote:
> On 12/01/2017 05:06 PM, Pavel Machek wrote:
> > Hi!
> >
> >> This adds basic support for BQ27521 battery monitor, used in Nokia N9
> >> and N950. In particular, battery voltage is important to be able to
> >> tell when the battery is almost empty. Emptying battery on N950 is
> >> pretty painful, as flasher needs to be used to recover phone in such
> >> case.
> >
> > Sebastian, ping? This one should not be too controversial.
>
> Acked-by: Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>
Thanks, queued, I dropped the spurious change in twl.h and added the
dt-binding from the previous patch version, that was lost somehow.
> > If you could also apply the "shut down when battery is low", that
> > would be nice.
I only have one with values specific to N900 hardcoded in the
driver. That one can't be applied for obvious reasons.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v7 2/2] dt-bindings: add eeprom "no-read-rollover" property
From: Sven Van Asbroeck @ 2017-12-08 16:28 UTC (permalink / raw)
To: svendev, robh+dt, mark.rutland, wsa, brgl, nsekhar, sakari.ailus,
david, javier, divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
In-Reply-To: <1512750511-24505-1-git-send-email-svendev@arcx.com>
Adds an optional property for at24 eeproms.
This parameterless property indicates that the multi-address eeprom
does not automatically roll over reads to the next slave address.
Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index 27f2bc1..a0415b8 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -38,6 +38,11 @@ Optional properties:
- size: total eeprom size in bytes
+ - no-read-rollover:
+ This parameterless property indicates that the multi-address
+ eeprom does not automatically roll over reads to the next
+ slave address. Please consult the manual of your device.
+
Example:
eeprom@52 {
--
1.9.1
^ permalink raw reply related
* [PATCH RESEND v7 1/2] at24: support eeproms that do not auto-rollover reads.
From: Sven Van Asbroeck @ 2017-12-08 16:28 UTC (permalink / raw)
To: svendev, robh+dt, mark.rutland, wsa, brgl, nsekhar, sakari.ailus,
david, javier, divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
In-Reply-To: <1512750511-24505-1-git-send-email-svendev@arcx.com>
Some multi-address eeproms in the at24 family may not automatically
roll-over reads to the next slave address. On those eeproms, reads
that straddle slave boundaries will not work correctly.
Solution:
Mark such eeproms with a flag that prevents reads straddling
slave boundaries. Add the AT24_FLAG_NO_RDROL flag to the eeprom
entry in the device_id table, or add 'no-read-rollover' to the
eeprom devicetree entry.
Note that I have not personally enountered an at24 chip that
does not support read rollovers. They may or may not exist.
However, my hardware requires this functionality because of
a quirk.
It's up to the Linux community to decide if this patch is useful/
general enough to warrant merging.
Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
---
drivers/misc/eeprom/at24.c | 39 ++++++++++++++++++++++++++------------
include/linux/platform_data/at24.h | 2 ++
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 625b001..06ffa11 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -251,15 +251,6 @@ struct at24_data {
* Slave address and byte offset derive from the offset. Always
* set the byte address; on a multi-master board, another master
* may have changed the chip's "current" address pointer.
- *
- * REVISIT some multi-address chips don't rollover page reads to
- * the next slave address, so we may need to truncate the count.
- * Those chips might need another quirk flag.
- *
- * If the real hardware used four adjacent 24c02 chips and that
- * were misconfigured as one 24c08, that would be a similar effect:
- * one "eeprom" file not four, but larger reads would fail when
- * they crossed certain pages.
*/
static struct at24_client *at24_translate_offset(struct at24_data *at24,
unsigned int *offset)
@@ -277,6 +268,30 @@ static struct at24_client *at24_translate_offset(struct at24_data *at24,
return &at24->client[i];
}
+static size_t at24_adjust_read_count(struct at24_data *at24,
+ unsigned int offset, size_t count)
+{
+ unsigned int bits;
+ size_t remainder;
+
+ /*
+ * In case of multi-address chips that don't rollover reads to
+ * the next slave address: truncate the count to the slave boundary,
+ * so that the read never straddles slaves.
+ */
+ if (at24->chip.flags & AT24_FLAG_NO_RDROL) {
+ bits = (at24->chip.flags & AT24_FLAG_ADDR16) ? 16 : 8;
+ remainder = BIT(bits) - offset;
+ if (count > remainder)
+ count = remainder;
+ }
+
+ if (count > io_limit)
+ count = io_limit;
+
+ return count;
+}
+
static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
unsigned int offset, size_t count)
{
@@ -289,9 +304,7 @@ static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
at24_client = at24_translate_offset(at24, &offset);
regmap = at24_client->regmap;
client = at24_client->client;
-
- if (count > io_limit)
- count = io_limit;
+ count = at24_adjust_read_count(at24, offset, count);
/* adjust offset for mac and serial read ops */
offset += at24->offset_adj;
@@ -457,6 +470,8 @@ static void at24_get_pdata(struct device *dev, struct at24_platform_data *chip)
if (device_property_present(dev, "read-only"))
chip->flags |= AT24_FLAG_READONLY;
+ if (device_property_present(dev, "no-read-rollover"))
+ chip->flags |= AT24_FLAG_NO_RDROL;
err = device_property_read_u32(dev, "size", &val);
if (!err)
diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
index 271a4e2..841bb28 100644
--- a/include/linux/platform_data/at24.h
+++ b/include/linux/platform_data/at24.h
@@ -50,6 +50,8 @@ struct at24_platform_data {
#define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */
#define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */
#define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */
+#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */
+ /* the next slave address */
void (*setup)(struct nvmem_device *nvmem, void *context);
void *context;
--
1.9.1
^ permalink raw reply related
* [PATCH v7 0/2] at24: support eeproms that do not auto-rollover reads.
From: Sven Van Asbroeck @ 2017-12-08 16:28 UTC (permalink / raw)
To: svendev, robh+dt, mark.rutland, wsa, brgl, nsekhar, sakari.ailus,
david, javier, divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
v7
rebased against at24 maintainer's devel staging branch:
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git at24/devel
v6 resend:
added Reviewed-by: Rob Herring <robh@kernel.org>
v6:
added newlines, asked by Bartosz
no need for braces around ternary operator's condition:
bits = (at24->chip.flags & AT24_FLAG_ADDR16) ? 16 : 8;
but keep the braces anyway, as asked by Uwe Klein-Koenig
v5:
at Rob Herring's request, renamed devicetree property:
at24,no-read-rollover -> no-read-rollover
v4:
renamed devicetree property:
no-read-rollover -> at24,no-read-rollover
dt-bindings update now a separate patch
v3:
rebased against at24 maintainer's devel staging branch:
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git at24/devel
clarified some of the comments and wording
v2:
kbuild test robot feedback: correct
"warning: comparison of distinct pointer types lacks a cast"
build warning on some compilers / architectures.
v1:
original patch
Sven Van Asbroeck (2):
at24: support eeproms that do not auto-rollover reads.
dt-bindings: add eeprom "at24,no-read-rollover" property
.../devicetree/bindings/eeprom/eeprom.txt | 5 +++
drivers/misc/eeprom/at24.c | 37 +++++++++++++++-------
include/linux/platform_data/at24.h | 2 ++
3 files changed, 32 insertions(+), 12 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [RFC] irqchip: add support for LS1021A external interrupt lines
From: Marc Zyngier @ 2017-12-08 16:09 UTC (permalink / raw)
To: Alexander Stein, Rasmus Villemoes
Cc: Thomas Gleixner, Jason Cooper, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2278177.dEyeroM47a@ws-stein>
On 08/12/17 15:11, Alexander Stein wrote:
> Hi Rasmus,
>
> thanks for your effort. unfortunatly I won't be able to test it currently :(
> But some comments below.
>
> On Friday, December 8, 2017, 3:33:00 PM CET Rasmus Villemoes wrote:
>> The LS1021A allows inverting the polarity of six interrupt lines
>> IRQ[0:5] via the scfg_intpcr register, effectively allowing
>> IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_EDGE_FALLING for those. We just need to
>> check the type, set the relevant bit in INTPCR accordingly, and fixup
>> the type argument before calling the GIC's irq_set_type.
>>
>> In fact, the power-on-reset value of the INTPCR register is so that all
>> six lines have their polarity inverted. Hence any hardware connected to
>> those lines is unusable without this: If the line is indeed active low,
>> the generic GIC code will reject an irq spec with IRQ_TYPE_LEVEL_LOW,
>> while if the line is active high, we must obviously disable the polarity
>> inversion before unmasking the interrupt.
>>
>> I suspect other layerscape SOCs may have something similar, but I have
>> neither hardware nor documentation.
>>
>> Since we only need to keep a single pointer in the chip_data (the syscon
>> regmap), the code could be a little simpler by dropping the struct
>> extirq_chip_data and just store the regmap directly - but I don't know
>> if I do need to add a lock or something else to the chip_data, so for
>> this RFC I've kept the struct.
>>
>> Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
>> ---
>> Marc, Alexander, thanks a lot for your hints. This is what I came up
>> with, mostly just copy-pasted from the mtk-sysirq case. I've tested
>> that it works as expected on my board.
>>
>> .../interrupt-controller/fsl,ls1021a-extirq.txt | 19 +++
>> drivers/irqchip/Makefile | 1 +
>> drivers/irqchip/irq-ls1021a.c | 157 +++++++++++++++++++++
>> 3 files changed, 177 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt
>> create mode 100644 drivers/irqchip/irq-ls1021a.c
>>
>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt
>> new file mode 100644
>> index 000000000000..53b04b6e1a80
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt
>> @@ -0,0 +1,19 @@
>> +* Freescale LS1021A external IRQs
>> +
>> +The LS1021A supports inverting the polarity of six external interrupt lines.
>> +
>> +Required properties:
>> +- compatible: should be "fsl,ls1021a-extirq"
>> +- interrupt-controller: Identifies the node as an interrupt controller
>> +- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
>
> Do you really need 3 interrupt-cells here? As you've written below you don't
> support PPI anyway the 1st flag might be dropped then. So support just 2 cells:
> * IRQ number (IRQ0 - IRQ5)
> * IRQ flags
The convention for irqchip stacked on top of a GIC is to keep the
interrupt specifier the same. It makes the maintenance if the DT much
easier, and doesn't hurt at all.
>
>> +- interrupt-parent: phandle of GIC.
>> +- syscon: phandle of Supplemental Configuration Unit (scfg).
>> +
>> +Example:
>> + extirq: interrupt-controller@15701ac {
>> + compatible = "fsl,ls1021a-extirq";
>> + #interrupt-cells = <3>;
>> + interrupt-controller;
>> + interrupt-parent = <&gic>;
>> + syscon = <&scfg>;
>> + };
>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>> index b842dfdc903f..d4576dce24b2 100644
>> --- a/drivers/irqchip/Makefile
>> +++ b/drivers/irqchip/Makefile
>> @@ -80,3 +80,4 @@ obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o
>> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
>> obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
>> obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o
>> +obj-$(CONFIG_SOC_LS1021A) += irq-ls1021a.o
>
> I guess this should be kept sorted alphabetically.
There is no such requirement. But grouping it next to the other FSL
irqchip would make more sense.
>
>> diff --git a/drivers/irqchip/irq-ls1021a.c b/drivers/irqchip/irq-ls1021a.c
>> new file mode 100644
>> index 000000000000..2ec4fc023549
>> --- /dev/null
>> +++ b/drivers/irqchip/irq-ls1021a.c
>> @@ -0,0 +1,157 @@
>> +#define pr_fmt(fmt) "irq-ls1021a: " fmt
>> +
>> +#include <linux/irq.h>
>> +#include <linux/irqchip.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/of.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/of_address.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +
>> +#define INTPCR_REG 0x01ac
>> +#define NIRQ 6
>> +
>> +struct extirq_chip_data {
>> + struct regmap *syscon;
>> +};
>> +
>> +static int
>> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type)
>> +{
>> + irq_hw_number_t hwirq = data->hwirq;
>> + struct extirq_chip_data *chip_data = data->chip_data;
>> + u32 value, mask;
>> + int ret;
>> +
>> + mask = 1U << (31 - hwirq);
>
> Is this really correct? IRQ0 is still at bit position 0. Don't be mislead
> by the left most position in the register layout. This is just strange way
> to express bit-endian access.
> Anyway, please use BIT(x) instead.
>
>> + if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING) {
>> + if (type == IRQ_TYPE_LEVEL_LOW)
>> + type = IRQ_TYPE_LEVEL_HIGH;
>> + else
>> + type = IRQ_TYPE_EDGE_RISING;
>> + value = mask;
>> + } else {
>> + value = 0;
>> + }
>> +
>> + /* Don't do the INTPCR_REG update if the parent irq_set_type will EINVAL. */
>> + if (type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
>> + return -EINVAL;
>
> I wonder if it is better to call data->parent_data->chip->irq_set_type(data, type)
> here instead and call regmap if this suceeded.
Not really. In both cases, you need to evaluate the failure (which is
not don here). So ordering doesn't matter. What actually matters is
error handling and atomicity (in this case, making sure that drivers
cannot observe an interrupt flood between the two reconfigurations).
>
>> + /* regmap does internal locking, but do we need to provide our
>> + * own across the parent irq_set_type call? */
>> + regmap_update_bits(chip_data->syscon, INTPCR_REG, mask, value);
>> +
>> + data = data->parent_data;
>> + ret = data->chip->irq_set_type(data, type);
>> +
>> + return ret;
>> +}
>> +
>> +static struct irq_chip extirq_chip = {
>> + .name = "LS1021A_EXTIRQ",
>> + .irq_mask = irq_chip_mask_parent,
>> + .irq_unmask = irq_chip_unmask_parent,
>> + .irq_eoi = irq_chip_eoi_parent,
>> + .irq_set_type = ls1021a_extirq_set_type,
>> + .irq_retrigger = irq_chip_retrigger_hierarchy,
>> + .irq_set_affinity = irq_chip_set_affinity_parent,
>> +};
>> +
>> +static int
>> +ls1021a_extirq_domain_translate(struct irq_domain *d, struct irq_fwspec *fwspec,
>> + unsigned long *hwirq, unsigned int *type)
>> +{
>> + if (!is_of_node(fwspec->fwnode))
>> + return -EINVAL;
>> +
>> + if (fwspec->param_count != 3)
>> + return -EINVAL;
>> +
>> + /* No PPI should point to this domain */
>> + if (fwspec->param[0] != 0)
>> + return -EINVAL;
>> +
>> + *hwirq = fwspec->param[1];
>
> Is a check for the hwirq value required here? I'm not an expert on
> irqchip API, so I just wonder.
In general, the driver is not in the business of validating the DT. But
that wouldn't hurt...
>
>> + *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
>> + return 0;
>> +}
>> +
>> +static int
>> +ls1021a_extirq_domain_alloc(struct irq_domain *domain, unsigned int virq,
>> + unsigned int nr_irqs, void *arg)
>> +{
>> + static const unsigned xlate[NIRQ] = {163,164,165,167,168,169};
> ^^^^^^
> No need for static here.
Why would you store this on the stack each time you enter the function?
That's the wrong construct (these values should come from DT), but
static is perfectly fine.
[...]
>> + domain_parent = irq_find_host(parent);
>> + if (!domain_parent) {
>> + pr_err("interrupt-parent not found\n");
>> + return -EINVAL;
>> + }
>
> Mh, does this mean if GIC has not been probed, this probe is not deferred?
> Is there an API to check for that?
This is not a normal driver, there is not deferred probing. You'd get
this error if the kernel had gone really wrong.
>
>> + chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
> ^^^^^^^
> devm_kzalloc
>> + if (!chip_data)
>> + return -ENOMEM;
>> +
>> + chip_data->syscon = syscon_regmap_lookup_by_phandle(node, "syscon");
>> + if (IS_ERR(chip_data->syscon)) {
>> + ret = PTR_ERR(chip_data->syscon);
>> + goto out_free_chip;
>> + }
>> +
>> + domain = irq_domain_add_hierarchy(domain_parent, 0, NIRQ, node,
>> + &extirq_domain_ops, chip_data);
>> + if (!domain) {
>> + ret = -ENOMEM;
>> + goto out_free_chip;
>> + }
>> +
>> + return 0;
>> +
>> +out_free_chip:
>> + kfree(chip_data);
>> + return ret;
>
> Using devm_kzalloc this label can be skipped.
Show me the struct device.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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: [RFC] irqchip: add support for LS1021A external interrupt lines
From: Marc Zyngier @ 2017-12-08 16:02 UTC (permalink / raw)
To: Rasmus Villemoes, Thomas Gleixner, Jason Cooper, Rob Herring,
Mark Rutland
Cc: Alexander Stein, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512743580-15358-1-git-send-email-rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
On 08/12/17 14:33, Rasmus Villemoes wrote:
> The LS1021A allows inverting the polarity of six interrupt lines
> IRQ[0:5] via the scfg_intpcr register, effectively allowing
> IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_EDGE_FALLING for those. We just need to
> check the type, set the relevant bit in INTPCR accordingly, and fixup
> the type argument before calling the GIC's irq_set_type.
>
> In fact, the power-on-reset value of the INTPCR register is so that all
> six lines have their polarity inverted. Hence any hardware connected to
> those lines is unusable without this: If the line is indeed active low,
> the generic GIC code will reject an irq spec with IRQ_TYPE_LEVEL_LOW,
> while if the line is active high, we must obviously disable the polarity
> inversion before unmasking the interrupt.
>
> I suspect other layerscape SOCs may have something similar, but I have
> neither hardware nor documentation.
>
> Since we only need to keep a single pointer in the chip_data (the syscon
> regmap), the code could be a little simpler by dropping the struct
> extirq_chip_data and just store the regmap directly - but I don't know
> if I do need to add a lock or something else to the chip_data, so for
> this RFC I've kept the struct.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
> ---
> Marc, Alexander, thanks a lot for your hints. This is what I came up
> with, mostly just copy-pasted from the mtk-sysirq case. I've tested
> that it works as expected on my board.
>
> .../interrupt-controller/fsl,ls1021a-extirq.txt | 19 +++
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-ls1021a.c | 157 +++++++++++++++++++++
> 3 files changed, 177 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt
> create mode 100644 drivers/irqchip/irq-ls1021a.c
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt
> new file mode 100644
> index 000000000000..53b04b6e1a80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt
> @@ -0,0 +1,19 @@
> +* Freescale LS1021A external IRQs
> +
> +The LS1021A supports inverting the polarity of six external interrupt lines.
> +
> +Required properties:
> +- compatible: should be "fsl,ls1021a-extirq"
> +- interrupt-controller: Identifies the node as an interrupt controller
> +- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
> +- interrupt-parent: phandle of GIC.
> +- syscon: phandle of Supplemental Configuration Unit (scfg).
> +
> +Example:
> + extirq: interrupt-controller@15701ac {
> + compatible = "fsl,ls1021a-extirq";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + interrupt-parent = <&gic>;
> + syscon = <&scfg>;
> + };
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index b842dfdc903f..d4576dce24b2 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -80,3 +80,4 @@ obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o
> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
> obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
> obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o
> +obj-$(CONFIG_SOC_LS1021A) += irq-ls1021a.o
> diff --git a/drivers/irqchip/irq-ls1021a.c b/drivers/irqchip/irq-ls1021a.c
> new file mode 100644
> index 000000000000..2ec4fc023549
> --- /dev/null
> +++ b/drivers/irqchip/irq-ls1021a.c
> @@ -0,0 +1,157 @@
> +#define pr_fmt(fmt) "irq-ls1021a: " fmt
> +
> +#include <linux/irq.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqdomain.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#define INTPCR_REG 0x01ac
> +#define NIRQ 6
These should come from the DT, specially if as suggested above, there
are other similar HW in the wild.
> +
> +struct extirq_chip_data {
> + struct regmap *syscon;
> +};
> +
> +static int
> +ls1021a_extirq_set_type(struct irq_data *data, unsigned int type)
> +{
> + irq_hw_number_t hwirq = data->hwirq;
> + struct extirq_chip_data *chip_data = data->chip_data;
> + u32 value, mask;
> + int ret;
> +
> + mask = 1U << (31 - hwirq);
> + if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING) {
> + if (type == IRQ_TYPE_LEVEL_LOW)
> + type = IRQ_TYPE_LEVEL_HIGH;
> + else
> + type = IRQ_TYPE_EDGE_RISING;
> + value = mask;
> + } else {
> + value = 0;
> + }
> +
> + /* Don't do the INTPCR_REG update if the parent irq_set_type will EINVAL. */
> + if (type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
> + return -EINVAL;
How about starting by rejecting the values that you cannot handle (which
seems to only be IRQ_TYPE_EDGE_BOTH)? Actually, if you wrote the whole
thing as a swtch/case, it'd be a lot more readable.
> +
> + /* regmap does internal locking, but do we need to provide our
> + * own across the parent irq_set_type call? */
Comment format.
> + regmap_update_bits(chip_data->syscon, INTPCR_REG, mask, value);
> +
> + data = data->parent_data;
> + ret = data->chip->irq_set_type(data, type);
Restore the previous regmap configuration on failure? Also, given that
you end-up changing the interrupt polarity in a non-atomic way (you have
two independent irqchips), it'd feel safer if you'd use
IRQCHIP_SET_TYPE_MASKED.
> +
> + return ret;
> +}
> +
> +static struct irq_chip extirq_chip = {
> + .name = "LS1021A_EXTIRQ",
Care to make this shorter?
> + .irq_mask = irq_chip_mask_parent,
> + .irq_unmask = irq_chip_unmask_parent,
> + .irq_eoi = irq_chip_eoi_parent,
> + .irq_set_type = ls1021a_extirq_set_type,
> + .irq_retrigger = irq_chip_retrigger_hierarchy,
> + .irq_set_affinity = irq_chip_set_affinity_parent,
> +};
> +
> +static int
> +ls1021a_extirq_domain_translate(struct irq_domain *d, struct irq_fwspec *fwspec,
> + unsigned long *hwirq, unsigned int *type)
> +{
> + if (!is_of_node(fwspec->fwnode))
> + return -EINVAL;
> +
> + if (fwspec->param_count != 3)
> + return -EINVAL;
> +
> + /* No PPI should point to this domain */
> + if (fwspec->param[0] != 0)
> + return -EINVAL;
> +
> + *hwirq = fwspec->param[1];
> + *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
> + return 0;
> +}
> +
> +static int
> +ls1021a_extirq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *arg)
> +{
> + static const unsigned xlate[NIRQ] = {163,164,165,167,168,169};
This should really come from your DT.
> + int i;
> + irq_hw_number_t hwirq;
> + struct irq_fwspec *fwspec = arg;
> + struct irq_fwspec gic_fwspec;
> +
> + if (fwspec->param_count != 3)
> + return -EINVAL;
> +
> + if (fwspec->param[0])
> + return -EINVAL;
> +
> + hwirq = fwspec->param[1];
> + for (i = 0; i < nr_irqs; i++)
This loop is pointless, as nr_irqs can only be >1 in the multi-MSI case.
> + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> + &extirq_chip,
> + domain->host_data);
> +
> + gic_fwspec.fwnode = domain->parent->fwnode;
> + gic_fwspec.param_count = 3;
> + gic_fwspec.param[0] = 0;
> + gic_fwspec.param[1] = xlate[hwirq];
> + gic_fwspec.param[2] = fwspec->param[2];
> +
> + return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, &gic_fwspec);
> +}
> +
> +static const struct irq_domain_ops extirq_domain_ops = {
> + .translate = ls1021a_extirq_domain_translate,
> + .alloc = ls1021a_extirq_domain_alloc,
> + .free = irq_domain_free_irqs_common,
> +};
> +
> +static int __init
> +ls1021a_extirq_of_init(struct device_node *node, struct device_node *parent)
> +{
> +
> + struct irq_domain *domain, *domain_parent;
> + struct extirq_chip_data *chip_data;
> + int ret;
> +
> + domain_parent = irq_find_host(parent);
> + if (!domain_parent) {
> + pr_err("interrupt-parent not found\n");
> + return -EINVAL;
> + }
> +
> + chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
> + if (!chip_data)
> + return -ENOMEM;
> +
> + chip_data->syscon = syscon_regmap_lookup_by_phandle(node, "syscon");
> + if (IS_ERR(chip_data->syscon)) {
> + ret = PTR_ERR(chip_data->syscon);
> + goto out_free_chip;
> + }
> +
> + domain = irq_domain_add_hierarchy(domain_parent, 0, NIRQ, node,
> + &extirq_domain_ops, chip_data);
> + if (!domain) {
> + ret = -ENOMEM;
> + goto out_free_chip;
> + }
> +
> + return 0;
> +
> +out_free_chip:
> + kfree(chip_data);
> + return ret;
> +}
> +
> +IRQCHIP_DECLARE(ls1021a_extirq, "fsl,ls1021a-extirq", ls1021a_extirq_of_init);
>
Overall, it is a bit annoying that you just copied the driver altogether
instead of trying to allow the common stuff to be shared between
drivers. Most of this is just boilerplate code...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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 RESEND v6 2/2] dt-bindings: add eeprom "no-read-rollover" property
From: Bartosz Golaszewski @ 2017-12-08 16:01 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: Rob Herring, Mark Rutland, Wolfram Sang, nsekhar, Sakari Ailus,
David Lechner, Javier Martinez Canillas, Divagar Mohandass,
devicetree, Linux Kernel Mailing List, linux-i2c
In-Reply-To: <1512747445-5817-3-git-send-email-svendev@arcx.com>
2017-12-08 16:37 GMT+01:00 Sven Van Asbroeck <svendev@arcx.com>:
> Adds an optional property for at24 eeproms.
> This parameterless property indicates that the multi-address eeprom
> does not automatically roll over reads to the next slave address.
>
> Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/eeprom/eeprom.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> index 27f2bc1..5bfc0ac 100644
> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -38,6 +38,11 @@ Optional properties:
>
> - size: total eeprom size in bytes
>
> + - no-read-rollover:
> + This parameterless property indicates that the multi-address
> + eeprom does not automatically roll over reads to the next
> + slave address. Please consult the manual of your device.
> +
> Example:
>
> eeprom@52 {
> --
> 1.9.1
>
Ugh this patch doesn't apply because I already applied the patch from
Wolfram which renamed the bindings document from eeprom.txt to
at24.txt. Please send another version rebased on top of my at24/devel
branch. I didn't notice it before.
Thanks,
Bartosz
^ permalink raw reply
* Re: [RESEND PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board
From: Alexandre Belloni @ 2017-12-08 15:57 UTC (permalink / raw)
To: Ludovic Desroches
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171207082453.10593-1-ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
On 07/12/2017 at 09:24:53 +0100, Ludovic Desroches wrote:
> Add the official SAMA5D2 Peripheral Touch Controller Evaluation
> Kit board.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
> Resend: Put SPDX-License-Identifier at the beginning of the file.
>
> Changes:
> - v2:
> - remove memory node
> - use SPDX-License-Identifier
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 401 ++++++++++++++++++++++++++++++
> 2 files changed, 402 insertions(+)
> create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: [RESEND PATCH v2] dt: bindings: as3645a: Fix the example node
From: Dan Murphy @ 2017-12-08 15:56 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds
In-Reply-To: <20171208155514.7696-1-dmurphy@ti.com>
Resent to include DT maintainers
On 12/08/2017 09:55 AM, Dan Murphy wrote:
> Fix the address-cells and size-cells example node
> to reflect to the correct representation.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> Acked-by: Pavel Machek <pavel@ucw.cz>
> ---
>
> v2 - Moved compatible to be first in the node - https://patchwork.kernel.org/patch/10092937/
>
> Documentation/devicetree/bindings/leds/ams,as3645a.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> index fdc40e354a64..fc7f5f9f234c 100644
> --- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> @@ -59,10 +59,10 @@ Example
> =======
>
> as3645a@30 {
Rob
Here is an example of the device name being part of the node name.
Should this be changed as well to leds@30?
Dan
> - #address-cells: 1
> - #size-cells: 0
> - reg = <0x30>;
> compatible = "ams,as3645a";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x30>;
> flash@0 {
> reg = <0x0>;
> flash-timeout-us = <150000>;
>
--
------------------
Dan Murphy
^ permalink raw reply
* [RESEND PATCH v2] dt: bindings: as3645a: Fix the example node
From: Dan Murphy @ 2017-12-08 15:55 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
Fix the address-cells and size-cells example node
to reflect to the correct representation.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
v2 - Moved compatible to be first in the node - https://patchwork.kernel.org/patch/10092937/
Documentation/devicetree/bindings/leds/ams,as3645a.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
index fdc40e354a64..fc7f5f9f234c 100644
--- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
+++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
@@ -59,10 +59,10 @@ Example
=======
as3645a@30 {
- #address-cells: 1
- #size-cells: 0
- reg = <0x30>;
compatible = "ams,as3645a";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x30>;
flash@0 {
reg = <0x0>;
flash-timeout-us = <150000>;
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* [PATCH] dt-bindings: pinctrl: stm32: fix copyright and adopt SPDX identifier
From: Alexandre Torgue @ 2017-12-08 15:53 UTC (permalink / raw)
To: Maxime Coquelin, Linus Walleij, Rob Herring, Mark Rutland
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Add missing copyright and add SPDX identifier.
Signed-off-by: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
diff --git a/include/dt-bindings/pinctrl/stm32-pinfunc.h b/include/dt-bindings/pinctrl/stm32-pinfunc.h
index b8dfe31..b5a2174 100644
--- a/include/dt-bindings/pinctrl/stm32-pinfunc.h
+++ b/include/dt-bindings/pinctrl/stm32-pinfunc.h
@@ -1,3 +1,9 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/*
+ * Copyright (C) STMicroelectronics 2017 - All Rights Reserved
+ * Author: Torgue Alexandre <alexandre.torgue-qxv4g6HH51o@public.gmane.org> for STMicroelectronics.
+ */
+
#ifndef _DT_BINDINGS_STM32_PINFUNC_H
#define _DT_BINDINGS_STM32_PINFUNC_H
--
2.7.4
--
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 v2 07/13] dt-bindings: power: reset: Document ocelot-reset binding
From: Alexandre Belloni @ 2017-12-08 15:46 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-kernel, Alexandre Belloni, Rob Herring,
devicetree, Sebastian Reichel, linux-pm
In-Reply-To: <20171208154618.20105-1-alexandre.belloni@free-electrons.com>
Add binding documentation for the Microsemi Ocelot reset block.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: Sebastian Reichel <sre@kernel.org>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
.../devicetree/bindings/power/reset/ocelot-reset.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
new file mode 100644
index 000000000000..1bcf276b04cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -0,0 +1,17 @@
+Microsemi Ocelot reset controller
+
+The DEVCPU_GCB:CHIP_REGS have a SOFT_RST register that can be used to reset the
+SoC MIPS core.
+
+Required Properties:
+ - compatible: "mscc,ocelot-chip-reset"
+
+Example:
+ syscon@71070000 {
+ compatible = "mscc,ocelot-chip-regs", "simple-mfd", "syscon";
+ reg = <0x71070000 0x1c>;
+
+ reset {
+ compatible = "mscc,ocelot-chip-reset";
+ };
+ };
--
2.15.1
^ permalink raw reply related
* [PATCH v2 06/13] dt-bindings: mips: Add bindings for Microsemi SoCs
From: Alexandre Belloni @ 2017-12-08 15:46 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-kernel, Alexandre Belloni, Rob Herring,
devicetree
In-Reply-To: <20171208154618.20105-1-alexandre.belloni@free-electrons.com>
Add bindings for Microsemi SoCs. Currently only Ocelot is supported.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
Documentation/devicetree/bindings/mips/mscc.txt | 46 +++++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mips/mscc.txt
diff --git a/Documentation/devicetree/bindings/mips/mscc.txt b/Documentation/devicetree/bindings/mips/mscc.txt
new file mode 100644
index 000000000000..1bb578b9d135
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/mscc.txt
@@ -0,0 +1,46 @@
+* Microsemi MIPS CPUs
+
+Boards with a SoC of the Microsemi MIPS family shall have the following
+properties:
+
+Required properties:
+- compatible: "mscc,ocelot"
+- mips-hpt-frequency: CPU counter frequency.
+
+
+* Other peripherals:
+
+o CPU chip regs:
+
+The SoC has a few registers (DEVCPU_GCB:CHIP_REGS) handling miscellaneous
+functionalities: chip ID, general purpose register for software use, reset
+controller, hardware status and configuration, efuses.
+
+Required properties:
+- compatible: Should be "mscc,ocelot-chip-regs", "simple-mfd", "syscon"
+- reg : Should contain registers location and length
+
+Example:
+ syscon@71070000 {
+ compatible = "mscc,ocelot-chip-regs", "simple-mfd", "syscon";
+ reg = <0x71070000 0x1c>;
+ };
+
+
+o CPU system control:
+
+The SoC has a few registers (ICPU_CFG:CPU_SYSTEM_CTRL) handling configuration of
+the CPU: 8 general purpose registers, reset control, CPU en/disabling, CPU
+endianess, CPU bus control, CPU status.
+
+Required properties:
+- compatible: Should be "mscc,ocelot-cpu-syscon", "syscon"
+- reg : Should contain registers location and length
+
+Example:
+ syscon@70000000 {
+ compatible = "mscc,ocelot-cpu-syscon", "syscon";
+ reg = <0x70000000 0x2c>;
+ };
+
+
--
2.15.1
^ permalink raw reply related
* [PATCH v2 00/13] MIPS: add support for the Microsemi MIPS SoCs
From: Alexandre Belloni @ 2017-12-08 15:46 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-kernel, Alexandre Belloni, Rob Herring,
devicetree, Thomas Gleixner, Jason Cooper, Linus Walleij,
linux-gpio, Sebastian Reichel, linux-pm
Hi,
This patch series adds initial support for the Microsemi MIPS SoCs. It
is currently focusing on the Microsemi Ocelot (VSC7513, VSC7514).
It adds support for the IRQ controller, pinmux and gpio controller and
reset control.
This produces a kernel that can boot to the console.
This is a single series for reference but it can also be taken
separately by each maintainer as each drivers are independant.
Changes in v2:
- removed the wildcard in MAINAINERS
- corrected the Cc list
- added proper documentation for both syscons
- removed the mscc,cpucontrol property
- updated the ranges property in the ocelot dtsi
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Cc: Sebastian Reichel <sre@kernel.org>
Cc: linux-pm@vger.kernel.org
Alexandre Belloni (13):
dt-bindings: Add vendor prefix for Microsemi Corporation
dt-bindings: interrupt-controller: Add binding for the Microsemi
Ocelot interrupt controller
irqchip: Add a driver for the Microsemi Ocelot controller
dt-bindings: pinctrl: Add bindings for Microsemi Ocelot
pinctrl: Add Microsemi Ocelot SoC driver
dt-bindings: mips: Add bindings for Microsemi SoCs
dt-bindings: power: reset: Document ocelot-reset binding
power: reset: Add a driver for the Microsemi Ocelot reset
MIPS: mscc: Add initial support for Microsemi MIPS SoCs
MIPS: mscc: add ocelot dtsi
MIPS: mscc: add ocelot PCB123 device tree
MIPS: defconfigs: add a defconfig for Microsemi SoCs
MAINTAINERS: Add entry for Microsemi MIPS SoCs
.../interrupt-controller/mscc,ocelot-icpu-intr.txt | 22 +
Documentation/devicetree/bindings/mips/mscc.txt | 46 ++
.../bindings/pinctrl/mscc,ocelot-pinctrl.txt | 39 ++
.../bindings/power/reset/ocelot-reset.txt | 17 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
MAINTAINERS | 7 +
arch/mips/Kbuild.platforms | 1 +
arch/mips/Kconfig | 24 +
arch/mips/boot/dts/Makefile | 1 +
arch/mips/boot/dts/mscc/Makefile | 6 +
arch/mips/boot/dts/mscc/ocelot.dtsi | 115 +++++
arch/mips/boot/dts/mscc/ocelot_pcb123.dts | 27 ++
arch/mips/configs/mscc_defconfig | 84 ++++
arch/mips/mscc/Makefile | 11 +
arch/mips/mscc/Platform | 12 +
arch/mips/mscc/setup.c | 106 +++++
drivers/irqchip/Kconfig | 5 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-mscc-ocelot.c | 109 +++++
drivers/pinctrl/Kconfig | 10 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-ocelot.c | 505 +++++++++++++++++++++
drivers/power/reset/Kconfig | 7 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/ocelot-reset.c | 86 ++++
25 files changed, 1244 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
create mode 100644 Documentation/devicetree/bindings/mips/mscc.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
create mode 100644 Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
create mode 100644 arch/mips/boot/dts/mscc/Makefile
create mode 100644 arch/mips/boot/dts/mscc/ocelot.dtsi
create mode 100644 arch/mips/boot/dts/mscc/ocelot_pcb123.dts
create mode 100644 arch/mips/configs/mscc_defconfig
create mode 100644 arch/mips/mscc/Makefile
create mode 100644 arch/mips/mscc/Platform
create mode 100644 arch/mips/mscc/setup.c
create mode 100644 drivers/irqchip/irq-mscc-ocelot.c
create mode 100644 drivers/pinctrl/pinctrl-ocelot.c
create mode 100644 drivers/power/reset/ocelot-reset.c
--
2.15.1
^ permalink raw reply
* Re: [PATCH v1 1/2] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-08 15:41 UTC (permalink / raw)
To: Peter Rosin
Cc: Bartosz Golaszewski, Sven Van Asbroeck, Wolfram Sang, nsekhar,
Sakari Ailus, Javier Martinez Canillas, Divagar Mohandass,
devicetree, Linux Kernel Mailing List, linux-i2c
In-Reply-To: <e68cff80-c8b8-ba32-fc40-5ff20a077480@axentia.se>
peda wrote:
> It's nice to be able to grep for compatible strings.
>
> $.02
>
Indeed. Bartosz and Peter, I think you're right.
Expect a v2 soon.
^ permalink raw reply
* Re: [PATCH v1 1/2] eeprom: at24: convert magic numbers to structs.
From: Peter Rosin @ 2017-12-08 15:39 UTC (permalink / raw)
To: Sven Van Asbroeck, Bartosz Golaszewski
Cc: Sven Van Asbroeck, Wolfram Sang, nsekhar, Sakari Ailus,
Javier Martinez Canillas, Divagar Mohandass, devicetree,
Linux Kernel Mailing List, linux-i2c
In-Reply-To: <CAGngYiXpwcjndtFhtCFhESagN9CRWiS0jFdndiNE2oupBQdDSw@mail.gmail.com>
On 2017-12-08 16:28, Sven Van Asbroeck wrote:
> Bartosz wrote:
>> Just make it accept two parameters: the string and the data object
>> name. For example:
>>
>> AT24_OF_DEVICE_ID("atmel,24c01", 24c01);
>>
>
> I don't want to do too much bikeshedding,
> but one last comment.
>
> Is it a good idea to have duplicated information?
> Do you think the risk of a typo mismatch is acceptable? E.g.
> AT24_OF_DEVICE_ID("atmel,24c01", 24c02);
>
> At least the original syntax is not susceptible to this problem,
> but of course as you say, it hides the of_ compatible string:
> AT24_OF_DEVICE_ID(atmel, 24c01);
> /* hides 'atmel,24c01' */
It's nice to be able to grep for compatible strings.
$.02
/peda
^ permalink raw reply
* [PATCH RESEND v6 2/2] dt-bindings: add eeprom "no-read-rollover" property
From: Sven Van Asbroeck @ 2017-12-08 15:37 UTC (permalink / raw)
To: svendev-fuHqz3Nb1YI, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wsa-z923LK4zBo2bacvFa/9K2g,
brgl-ARrdPY/1zhM, nsekhar-l0cyMroinI0,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA, david-nq/r/kbU++upp/zk7JDF2g,
javier-0uQlZySMnqxg9hUCZPvPmw,
divagar.mohandass-ral2JQCrhuEAvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512747445-5817-1-git-send-email-svendev-fuHqz3Nb1YI@public.gmane.org>
Adds an optional property for at24 eeproms.
This parameterless property indicates that the multi-address eeprom
does not automatically roll over reads to the next slave address.
Signed-off-by: Sven Van Asbroeck <svendev-fuHqz3Nb1YI@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/eeprom/eeprom.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 27f2bc1..5bfc0ac 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -38,6 +38,11 @@ Optional properties:
- size: total eeprom size in bytes
+ - no-read-rollover:
+ This parameterless property indicates that the multi-address
+ eeprom does not automatically roll over reads to the next
+ slave address. Please consult the manual of your device.
+
Example:
eeprom@52 {
--
1.9.1
--
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
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