* Re: [PATCH v3 4/4] regulator: core: Balance coupled regulators voltages
From: Mark Brown @ 2017-12-15 15:19 UTC (permalink / raw)
To: Maciej Purski
Cc: linux-kernel, devicetree, Liam Girdwood, Rob Herring,
Mark Rutland, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <0bca0d20-1ca8-be4c-a60e-bbc0c640ae41@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Wed, Dec 13, 2017 at 10:25:00AM +0100, Maciej Purski wrote:
> > shared. To that end I'd adjust the code so that we always have a
> > coupling descriptor and then handle the case where there's only one
> > regulator described in there.
> Do you have any suggestion, how should I implement that path? The thing which
> makes it more complicated is locking, because set_voltage_unlocked is done
> under one regulator's mutex and its suppliers, while balance procedure locks
> every coupled regulator without its suppliers. The suppliers for a single
> regulator are locked when setting a single regulator's voltage takes place.
We only really need to lock the supplies when doing the actual mechanics
of voltage changes so I'm not sure I see a big issue here - if we always
go through balancing first then voltage setting it should be fine. If
everything is always balancing (even uncoupled regulators) then part of
the transition should be moving some if not all of the data updates to
balancing.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stübner @ 2017-12-15 15:20 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Mark Rutland, Emil Renner Berthing, Huibin Hong, Catalin Marinas,
Linus Walleij, Will Deacon, Kever Yang, LKML, Klaus Goger,
Joseph Chen, Romain Perier, Matthias Kaehlcke, Sugar Zhang,
Simon Xue, Heinrich Schuchardt, Brian Norris, Russell King,
Jaehoon Chung, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Chen-Yu Tsai, Jacob Chen, Jianqun Xu, Shawn Lin
In-Reply-To: <CAOFm3uHuwmU1nCcU1MQ9qgGZ0A70ycuoo8XpWcDzgPQFzFRnRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Am Freitag, 15. Dezember 2017, 15:42:48 CET schrieb Philippe Ombredanne:
> On Fri, Dec 15, 2017 at 3:28 PM, Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> > Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
> >> Klaus,
> >>
> >> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
> >>
> >> <klaus.goger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org> wrote:
> >> > This patch series replaces all the license text in rockchip devicetree
> >> > files text with a proper SPDX-License-Identifier.
> >> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
> >> > yet merged.
> >> >
> >> > These series also fixes the issue with contradicting statements in most
> >> > licenses. The introduction text claims to be GPL or X11[2] but the
> >> > following verbatim copy of the license is actually a MIT[3] license.
> >> > The X11 license includes a advertise clause and trademark information
> >> > related to the X Consortium. As these X Consortium specfic points are
> >> > irrelevant for us we stick with the actuall license text.
> >> >
> >> > [1] https://patchwork.kernel.org/patch/10091607/
> >> > [2] https://spdx.org/licenses/X11.html
> >> > [3] https://spdx.org/licenses/MIT.html
> >>
> >> FWIW, the X11 license name was not always something clearly defined.
> >> SPDX calls it clearly MIT which is the most widely accepted name for
> >> the corresponding text. And this is also what we have in Thomas doc
> >> patches that should be the kernel reference.
> >>
> >> Also, as a general note, you want to make sure that such as patch set
> >> is not merged by mistake until you have collected an explicit review
> >> or ack from all the copyright holders involved.
> >
> > Just for my understanding, is it really necessary to get Acks from _all_
> > previous contributors?
> >
> > I see that Thomas patches moving license texts into the kernel itself do
> > not seem to have landed yet, but when the actual license text does _not_
> > change and only its location to a common place inside the kernel sources,
> > it feels a bit overkill trying to get Acks from _everybody_ that
> > contributed to Rockchip devicetrees for the last 4 years.
> >
> > If we would actually want to change the license I would definitly feel
> > differently, but the license text does not change.
>
> Well you are technically right. But there is a social and politeness
> angle to this too. So may be getting the ack of all contributors is
> not always needed, but getting it is best and the right to do and at
> least getting for the named copyright holders should be there.
>
> That's only only my take: leaving aside any technical legal issue, say
> I would be on the receiving end as one of the holder or contributors:
> I would find it really great and nice to have my ack requested. And I
> would be a dork not to give it. So I like to do to others the same I
> would appreciate done to me (within reason, as I sometimes shoot
> myself in the foot ;) )
Hehe ... I didn't plan on merging this without ample time for people
to either ACK or NAK the change, so was planning on keeping to social
protocol ;-) . Just the "all" threw me for a loop.
And having that as PATCH without RFC also communicates that people
should take a look, as RFC patches are often overlooked.
As Klaus seems to have included most people that have contributed in the
past, I would guess we should receive any existing complaints about that
change :-) .
So I'll definitly let this simmer for quite a bit and do a best-effort Ack
collection.
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: bcm_sf2: Update compatible string for 7278B0
From: David Miller @ 2017-12-15 15:57 UTC (permalink / raw)
To: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215015941.32443-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 14 Dec 2017 17:59:40 -0800
> Update the compatible string and Device Tree binding document for
> 7278B0.
>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied.
--
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 v5 3/3] PCI: mobiveil: Add MSI support for Mobiveil PCIe Host
From: Marc Zyngier @ 2017-12-15 16:13 UTC (permalink / raw)
To: Subrahmanya Lingappa, linux-pci, bhelgaas, lorenzo.pieralisi,
robh
Cc: devicetree, mingkai.hu, peter.newton, minghuan.lian, rajesh.raina,
rajan.kapoor, prabhjot.singh
In-Reply-To: <1513181336-19955-1-git-send-email-l.subrahmanya@mobiveil.co.in>
On 13/12/17 16:08, Subrahmanya Lingappa wrote:
> Adds MSI support for Mobiveil PCIe Host Bridge IP driver
>
> Signed-off-by: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: linux-pci@vger.kernel.org
> ---
> drivers/pci/host/pcie-mobiveil.c | 222 ++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 220 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-mobiveil.c b/drivers/pci/host/pcie-mobiveil.c
> index 8611aaa..39818d5 100644
> --- a/drivers/pci/host/pcie-mobiveil.c
> +++ b/drivers/pci/host/pcie-mobiveil.c
> @@ -14,6 +14,7 @@
> #include <linux/irqdomain.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> +#include <linux/msi.h>
> #include <linux/of_address.h>
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> @@ -55,6 +56,7 @@
> #define PAB_INTP_AMBA_MISC_ENB 0x0b0c
> #define PAB_INTP_AMBA_MISC_STAT 0x0b1c
> #define PAB_INTP_INTX_MASK 0x1e0
> +#define PAB_INTP_MSI_MASK 0x8
>
> #define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR_16(0x0ba0, win)
> #define WIN_ENABLE_SHIFT 0
> @@ -85,8 +87,19 @@
>
> /* supported number of interrupts */
> #define PCI_NUM_INTX 4
> +#define PCI_NUM_MSI 16
> #define PAB_INTA_POS 5
>
> +/* MSI registers */
> +#define MSI_BASE_LO_OFFSET 0x04
> +#define MSI_BASE_HI_OFFSET 0x08
> +#define MSI_SIZE_OFFSET 0x0c
> +#define MSI_ENABLE_OFFSET 0x14
> +#define MSI_STATUS_OFFSET 0x18
> +#define MSI_DATA_OFFSET 0x20
> +#define MSI_ADDR_L_OFFSET 0x24
> +#define MSI_ADDR_H_OFFSET 0x28
> +
> /* outbound and inbound window definitions */
> #define WIN_NUM_0 0
> #define WIN_NUM_1 1
> @@ -105,11 +118,22 @@
> #define UINT64_MAX (u64)(~((u64)0))
> #endif
>
> +struct mobiveil_msi { /* MSI information */
> + struct mutex lock; /* protect bitmap variable */
> + struct irq_domain *msi_domain;
> + struct irq_domain *dev_domain;
> + phys_addr_t msi_pages_phys;
> + int *msi_pages;
> + int num_of_vectors;
> + DECLARE_BITMAP(msi_irq_in_use, PCI_NUM_MSI);
> +};
> +
> struct mobiveil_pcie {
> struct platform_device *pdev;
> struct list_head resources;
> void __iomem *config_axi_slave_base; /* endpoint config base */
> void __iomem *csr_axi_slave_base; /* root port config base */
> + void __iomem *apb_csr_base; /* MSI register base */
> struct irq_domain *intx_domain;
> int irq;
> int apio_wins;
> @@ -118,6 +142,7 @@ struct mobiveil_pcie {
> int ib_wins_configured; /* configured inbound windows */
> struct resource *ob_io_res;
> char root_bus_nr;
> + struct mobiveil_msi msi;
> };
>
> static inline void csr_writel(struct mobiveil_pcie *pcie, const u32 value,
> @@ -202,11 +227,18 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> struct irq_chip *chip = irq_desc_get_chip(desc);
> struct mobiveil_pcie *pcie = irq_desc_get_handler_data(desc);
> struct device *dev = &pcie->pdev->dev;
> - u32 intr_status;
> + struct mobiveil_msi *msi = &pcie->msi;
> + u32 msi_data, msi_addr_lo, msi_addr_hi;
> + u32 intr_status, msi_status;
> unsigned long shifted_status;
> u32 bit, virq;
> u32 val, mask;
>
> + /*
> + * The core provides a single interrupt for both INTx/MSI messages.
> + * So we'll read both INTx and MSI status
> + */
> +
> chained_irq_enter(chip, desc);
>
> /* read INTx status */
> @@ -241,6 +273,41 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> } while ((shifted_status >> PAB_INTA_POS) != 0);
> }
>
> + /* read extra MSI status register */
> + msi_status = readl(pcie->apb_csr_base + MSI_STATUS_OFFSET);
You are using the non-relaxed accessors here, while the rest of the
driver used the _relaxed version. Why is that so?
> +
> + /* handle MSI interrupts */
> + if ((intr_status & PAB_INTP_MSI_MASK) || (msi_status & 1)) {
> + do {
> + msi_data = readl(pcie->apb_csr_base + MSI_DATA_OFFSET);
> +
> + /*
> + * MSI_STATUS_OFFSET gets updated to zero once we have
> + * popped not only the data but also address from MSI
> + * hardware FIFO.so keeping these following two dummy
> + * reads.
> + */
> + msi_addr_lo = readl(pcie->apb_csr_base +
> + MSI_ADDR_L_OFFSET);
> + msi_addr_hi = readl(pcie->apb_csr_base +
> + MSI_ADDR_H_OFFSET);
Is that really valid? Don't you have to issue a 64bit access?
> + dev_dbg(dev,
> + "MSI registers, data: %08x, addr: %08x:%08x\n",
> + msi_data, msi_addr_hi, msi_addr_lo);
> +
> + if (msi_data) {
> + virq = irq_find_mapping(msi->dev_domain,
> + msi_data);
> + if (virq)
> + generic_handle_irq(virq);
> + } else
> + dev_err_ratelimited(dev, "MSI data null\n");
Braces on both sides of the else statement.
Also, why is msi_data==0 not valid? You can definitely allocate it from
your bitmap, and I'm expecting that there is a strong correlation
between what you read from MSI_DATA_OFFSET and the payload that the
endpoint writes.
> +
> + msi_status = readl(pcie->apb_csr_base +
> + MSI_STATUS_OFFSET);
> + } while (msi_status & 1);
> + }
> +
> csr_writel(pcie, intr_status, PAB_INTP_AMBA_MISC_STAT);
> chained_irq_exit(chip, desc);
> }
> @@ -274,6 +341,12 @@ static int mobiveil_pcie_parse_dt(struct mobiveil_pcie *pcie)
> if (IS_ERR(pcie->csr_axi_slave_base))
> return PTR_ERR(pcie->csr_axi_slave_base);
>
> + /* map MSI config resource */
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "apb_csr");
> + pcie->apb_csr_base = devm_pci_remap_cfg_resource(dev, res);
> + if (IS_ERR(pcie->apb_csr_base))
> + return PTR_ERR(pcie->apb_csr_base);
> +
> /* read the number of windows requested */
> if (!pcie->apio_wins &&
> of_property_read_u32(node, "apio-wins", &pcie->apio_wins)) {
> @@ -430,6 +503,27 @@ static int mobiveil_bringup_link(struct mobiveil_pcie *pcie)
> return -ETIMEDOUT;
> }
>
> +static void mobiveil_pcie_enable_msi(struct mobiveil_pcie *pcie)
> +{
> + phys_addr_t msg_addr;
> + struct mobiveil_msi *msi = &pcie->msi;
> +
> +
> + pcie->msi.num_of_vectors = PCI_NUM_MSI;
> +
> + msi->msi_pages = (void *)__get_free_pages(GFP_DMA, 0);
That old trick again... Do you really need to carve out a RAM page for
this? Can't you use just some dummy physical address instead? The base
address of your PCIe RC, for example.
> + msg_addr = virt_to_phys((void *)msi->msi_pages);
> + msi->msi_pages_phys = (phys_addr_t)msg_addr;
> +
> + writel_relaxed(lower_32_bits(msg_addr),
> + pcie->apb_csr_base + MSI_BASE_LO_OFFSET);
> + writel_relaxed(upper_32_bits(msg_addr),
> + pcie->apb_csr_base + MSI_BASE_HI_OFFSET);
> + writel_relaxed(4096, pcie->apb_csr_base + MSI_SIZE_OFFSET);
> + writel_relaxed(1,
> + pcie->apb_csr_base + MSI_ENABLE_OFFSET);
nit: No need to break all these writes, each of them can fit on a single
line.
> +}
> +
> static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> {
> u32 value;
> @@ -465,7 +559,8 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> (1 << PEX_PIO_ENABLE_SHIFT),
> PAB_CTRL);
>
> - csr_writel(pcie, PAB_INTP_INTX_MASK, PAB_INTP_AMBA_MISC_ENB);
> + csr_writel(pcie, (PAB_INTP_INTX_MASK | PAB_INTP_MSI_MASK),
> + PAB_INTP_AMBA_MISC_ENB);
>
> /* program PIO Enable Bit to 1 and Config Window Enable Bit to 1 in
> * PAB_AXI_PIO_CTRL Register
> @@ -503,6 +598,10 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> }
> }
>
> + /* setup MSI hardware registers */
> + if (IS_ENABLED(CONFIG_PCI_MSI))
Your driver already depends on PCI_MSI_IRQ_DOMAIN, which depends on
PCI_MSI. So this IS_ENABLED() is pointless.
> + mobiveil_pcie_enable_msi(pcie);
> +
> return err;
> }
>
> @@ -520,6 +619,118 @@ static int mobiveil_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
> .map = mobiveil_pcie_intx_map,
> };
>
> +static struct irq_chip mobiveil_msi_irq_chip = {
> + .name = "Mobiveil PCIe MSI",
> + .irq_mask = pci_msi_mask_irq,
> + .irq_unmask = pci_msi_unmask_irq,
> +};
> +
> +static struct msi_domain_info mobiveil_msi_domain_info = {
> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> + MSI_FLAG_PCI_MSIX),
> + .chip = &mobiveil_msi_irq_chip,
> +};
> +
> +static void mobiveil_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct mobiveil_pcie *pcie = irq_data_get_irq_chip_data(data);
> + phys_addr_t addr = virt_to_phys((void *)pcie->msi.msi_pages +
> + (data->hwirq * sizeof(int)));
> +
> + msg->address_lo = lower_32_bits(addr);
> + msg->address_hi = upper_32_bits(addr);
> + msg->data = data->hwirq;
> +
> + dev_dbg(&pcie->pdev->dev, "msi#%d address_hi %#x address_lo %#x\n",
> + (int)data->hwirq, msg->address_hi, msg->address_lo);
> +}
> +
> +static int mobiveil_msi_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> + return -EINVAL;
> +}
> +
> +static struct irq_chip mobiveil_msi_bottom_irq_chip = {
> + .name = "Mobiveil MSI",
> + .irq_compose_msi_msg = mobiveil_compose_msi_msg,
> + .irq_set_affinity = mobiveil_msi_set_affinity,
> +};
> +
> +static int mobiveil_irq_msi_domain_alloc(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs, void *args)
> +{
> + struct mobiveil_pcie *pcie = domain->host_data;
> + struct mobiveil_msi *msi = &pcie->msi;
> + unsigned long bit;
> +
> + WARN_ON(nr_irqs != 1);
> + mutex_lock(&msi->lock);
> +
> + bit = find_first_zero_bit(msi->msi_irq_in_use, msi->num_of_vectors);
> + if (bit >= msi->num_of_vectors) {
> + mutex_unlock(&msi->lock);
> + return -ENOSPC;
> + }
> +
> + set_bit(bit, msi->msi_irq_in_use);
> +
> + mutex_unlock(&msi->lock);
> +
> + irq_domain_set_info(domain, virq, bit, &mobiveil_msi_bottom_irq_chip,
> + domain->host_data, handle_simple_irq,
> + NULL, NULL);
> + return 0;
> +}
> +
> +static void mobiveil_irq_msi_domain_free(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs)
> +{
> + struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> + struct mobiveil_pcie *pcie = irq_data_get_irq_chip_data(d);
> + struct mobiveil_msi *msi = &pcie->msi;
> +
> + mutex_lock(&msi->lock);
> +
> + if (!test_bit(d->hwirq, msi->msi_irq_in_use)) {
> + dev_err(&pcie->pdev->dev, "trying to free unused MSI#%lu\n",
> + d->hwirq);
> + } else {
> + __clear_bit(d->hwirq, msi->msi_irq_in_use);
> + }
> +
> + mutex_unlock(&msi->lock);
> +}
> +
> +static const struct irq_domain_ops msi_domain_ops = {
> + .alloc = mobiveil_irq_msi_domain_alloc,
> + .free = mobiveil_irq_msi_domain_free,
> +};
> +
> +static int mobiveil_allocate_msi_domains(struct mobiveil_pcie *pcie)
> +{
> + struct device *dev = &pcie->pdev->dev;
> + struct fwnode_handle *fwnode = of_node_to_fwnode(dev->of_node);
> + struct mobiveil_msi *msi = &pcie->msi;
> +
> + mutex_init(&pcie->msi.lock);
> + msi->dev_domain = irq_domain_add_linear(NULL, msi->num_of_vectors,
> + &msi_domain_ops, pcie);
> + if (!msi->dev_domain) {
> + dev_err(dev, "failed to create IRQ domain\n");
> + return -ENOMEM;
> + }
> +
> + msi->msi_domain = pci_msi_create_irq_domain(fwnode,
> + &mobiveil_msi_domain_info, msi->dev_domain);
> + if (!msi->msi_domain) {
> + dev_err(dev, "failed to create MSI domain\n");
> + irq_domain_remove(msi->dev_domain);
> + return -ENOMEM;
> + }
> + return 0;
> +}
> +
> static int mobiveil_pcie_init_irq_domain(struct mobiveil_pcie *pcie)
> {
> struct device *dev = &pcie->pdev->dev;
> @@ -535,6 +746,13 @@ static int mobiveil_pcie_init_irq_domain(struct mobiveil_pcie *pcie)
> return -ENODEV;
> }
>
> +#ifdef CONFIG_PCI_MSI
Useless #ifdef
> + /* setup MSI */
> + ret = mobiveil_allocate_msi_domains(pcie);
> + if (ret)
> + return ret;
> +#endif
> +
> return 0;
> }
>
>
Now, there is something that I find a bit annoying: This code looks very
similar to drivers/pci/host/pcie-altera-msi.c, to the extent that I
suspect this is the same IP.
I suggest you investigate whether you can reuse the existing code
instead of adding yet another MSI driver to the kernel.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: klaus.goger @ 2017-12-15 16:27 UTC (permalink / raw)
To: Heiko Stübner
Cc: Mark Rutland, Emil Renner Berthing, Huibin Hong, Catalin Marinas,
Linus Walleij, Will Deacon, Kever Yang, LKML, Finley Xiao,
Joseph Chen, Romain Perier, Randy Li, Matthias Kaehlcke,
Sugar Zhang, Simon Xue, Heinrich Schuchardt, Brian Norris,
Russell King, FUKAUMI Naoki, Jaehoon Chung, linux-rockchip,
Chen-Yu Tsai, Jacob Chen, Jagan
In-Reply-To: <63058496.Aj9cacRib9@diego>
> On 15.12.2017, at 16:20, Heiko Stübner <heiko@sntech.de> wrote:
>
> Am Freitag, 15. Dezember 2017, 15:42:48 CET schrieb Philippe Ombredanne:
>> On Fri, Dec 15, 2017 at 3:28 PM, Heiko Stübner <heiko@sntech.de> wrote:
>>> Am Freitag, 15. Dezember 2017, 14:45:34 CET schrieb Philippe Ombredanne:
>>>> Klaus,
>>>>
>>>> On Fri, Dec 15, 2017 at 12:44 PM, Klaus Goger
>>>>
>>>> <klaus.goger@theobroma-systems.com> wrote:
>>>>> This patch series replaces all the license text in rockchip devicetree
>>>>> files text with a proper SPDX-License-Identifier.
>>>>> It follows the guidelines submitted[1] by Thomas Gleixner that are not
>>>>> yet merged.
>>>>>
>>>>> These series also fixes the issue with contradicting statements in most
>>>>> licenses. The introduction text claims to be GPL or X11[2] but the
>>>>> following verbatim copy of the license is actually a MIT[3] license.
>>>>> The X11 license includes a advertise clause and trademark information
>>>>> related to the X Consortium. As these X Consortium specfic points are
>>>>> irrelevant for us we stick with the actuall license text.
>>>>>
>>>>> [1] https://patchwork.kernel.org/patch/10091607/
>>>>> [2] https://spdx.org/licenses/X11.html
>>>>> [3] https://spdx.org/licenses/MIT.html
>>>>
>>>> FWIW, the X11 license name was not always something clearly defined.
>>>> SPDX calls it clearly MIT which is the most widely accepted name for
>>>> the corresponding text. And this is also what we have in Thomas doc
>>>> patches that should be the kernel reference.
>>>>
>>>> Also, as a general note, you want to make sure that such as patch set
>>>> is not merged by mistake until you have collected an explicit review
>>>> or ack from all the copyright holders involved.
>>>
>>> Just for my understanding, is it really necessary to get Acks from _all_
>>> previous contributors?
>>>
>>> I see that Thomas patches moving license texts into the kernel itself do
>>> not seem to have landed yet, but when the actual license text does _not_
>>> change and only its location to a common place inside the kernel sources,
>>> it feels a bit overkill trying to get Acks from _everybody_ that
>>> contributed to Rockchip devicetrees for the last 4 years.
>>>
>>> If we would actually want to change the license I would definitly feel
>>> differently, but the license text does not change.
>>
>> Well you are technically right. But there is a social and politeness
>> angle to this too. So may be getting the ack of all contributors is
>> not always needed, but getting it is best and the right to do and at
>> least getting for the named copyright holders should be there.
>>
>> That's only only my take: leaving aside any technical legal issue, say
>> I would be on the receiving end as one of the holder or contributors:
>> I would find it really great and nice to have my ack requested. And I
>> would be a dork not to give it. So I like to do to others the same I
>> would appreciate done to me (within reason, as I sometimes shoot
>> myself in the foot ;) )
>
> Hehe ... I didn't plan on merging this without ample time for people
> to either ACK or NAK the change, so was planning on keeping to social
> protocol ;-) . Just the "all" threw me for a loop.
>
> And having that as PATCH without RFC also communicates that people
> should take a look, as RFC patches are often overlooked.
>
> As Klaus seems to have included most people that have contributed in the
> past, I would guess we should receive any existing complaints about that
> change :-) .
I added the full list from the get_maintainers script. Some of the original authors
got dropped as the current contribution level dropped below the scripts limit.
I added the missing email addresses from the copyright headers to the CC list.
Convenience links to the original patches for the added people:
https://patchwork.kernel.org/patch/10114845/
https://patchwork.kernel.org/patch/10114843/
> So I'll definitly let this simmer for quite a bit and do a best-effort Ack
> collection.
Thanks,
Klaus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] PM / OPP: Introduce ti-opp-supply driver
From: Tony Lindgren @ 2017-12-15 16:30 UTC (permalink / raw)
To: Dave Gerlach
Cc: Viresh Kumar, Rob Herring, Rafael J . Wysocki,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon
In-Reply-To: <20171215042528.28715-1-d-gerlach-l0cyMroinI0@public.gmane.org>
* Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> [171215 04:28]:
> Hi,
> This is v2 of the series to introduce the ti-opp-supply driver which makes
> use of the OPP core to enable multiple regulator DVFS and AVS Class0 for
> TI DRA7 and AM57 platforms. Version 1 of this series can be found here [1].
Good to see this :) For the whole series:
Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 04/14] ARM: dts: dra76x: Create a common file with MMC/SD IOdelay data
From: Tony Lindgren @ 2017-12-15 16:32 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: bcousson, Santosh Shilimkar, Rob Herring, Mark Rutland,
Russell King, linux-mmc, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, nsekhar
In-Reply-To: <be4d8cfd-bdd3-aedf-9d9c-156de39d2621@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [171215 06:12]:
> Hi Tony,
>
> On Thursday 14 December 2017 08:45 PM, Tony Lindgren wrote:
> > * Kishon Vijay Abraham I <kishon@ti.com> [171214 13:44]:
> >> +&dra7_pmx_core {
> >> + mmc1_pins_default: mmc1_pins_default {
> >> + pinctrl-single,pins = <
> >> + DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
> >> + DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
> >> + DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
> >> + DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
> >> + DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
> >> + DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
> >> + >;
> >> + };
> >> +
> >> + mmc1_pins_sdr12: mmc1_pins_sdr12 {
> >> + pinctrl-single,pins = <
> >> + DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
> >> + DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
> >> + DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
> >> + DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
> >> + DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
> >> + DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
> >> + >;
> >> + };
> >
> > Can't you just do:
> >
> > pinctrl-0 = <&mmc1_pins_default>;
> > pinctrl-1 = <&mmc1_pins_default>;
> > pinctrl-2 = <&mmc1_pins_hs>;
> > pinctrl-names = "default", "sdr12", "sdr25";
>
> just wanted to make sure every mode has it's own pinctrl group so that it's
> easy to review. Initially we were thinking something like
> mmc1_pins_default_sdr12_sdr25.
OK that naming works fine for me.
> But if you'd prefer we just use mmc1_pins_default for all modes that uses
> default pinmux configuration, I can change it that way too.
No up to you with the naming thanks.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 18/25] arm: am3/am4/dra7/omap: dts: Remove leading 0x and 0s from bindings notation
From: Tony Lindgren @ 2017-12-15 16:39 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Rob Herring, Benoît Cousson, Mark Rutland, Russell King,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215124651.30793-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
* Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> [171215 04:49]:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Thanks applying this patch into omap-for-v4.16/dt.
Regards,
Tony
--
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] ARM: dts: am437x-gp-evm: Add phandle for the backlight for the panel
From: Tony Lindgren @ 2017-12-15 16:41 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20171215120932.21572-1-peter.ujfalusi-l0cyMroinI0@public.gmane.org>
* Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [171215 04:12]:
> With the backlight phandle the driver can manage the backlight on/off in
> sync with the panel enable/disable.
Applying into omap-for-v4.16/dt thanks,
Tony
--
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] ARM: dts: am437x-sk-evm: Add phandle for the backlight for the panel
From: Tony Lindgren @ 2017-12-15 16:42 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20171215120941.21638-1-peter.ujfalusi-l0cyMroinI0@public.gmane.org>
* Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [171215 04:12]:
> With the backlight phandle the driver can manage the backlight on/off in
> sync with the panel enable/disable.
Applying into omap-for-v4.16/dt thanks,
Tony
--
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] ARM: dts: am43xx-epos-evm: Add phandle for the backlight for the panel
From: Tony Lindgren @ 2017-12-15 16:42 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20171215120954.21711-1-peter.ujfalusi-l0cyMroinI0@public.gmane.org>
* Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [171215 04:12]:
> With the backlight phandle the driver can manage the backlight on/off in
> sync with the panel enable/disable.
Applying into omap-for-v4.16/dt thanks,
Tony
--
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] ARM: dts: am43xx: Fix inverted DS0_PULL_UP_DOWN_EN macro
From: Tony Lindgren @ 2017-12-15 16:44 UTC (permalink / raw)
To: Dave Gerlach
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171213212443.22632-1-d-gerlach-l0cyMroinI0@public.gmane.org>
* Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> [171213 13:27]:
> Due to a mistake in documentation the DS0_PULL_UP_DOWN_EN macro was
> mistakenly defined as an active high bit, however setting the bit
> actually disables the internal pull resistor on the pin, so correct this
> macro and introduce a new DS0_PULL_UP_DOWN_DIS macro with the proper bit
> value set now that the documentation has been updated.
>
> Change based on AM437x Techninal Reference Manual SPRUHL7G Revised June
> 2017 Section 7.2.1.
Applying into omap-for-v4.16/dt thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v11 1/3] Documentation: Add device tree binding for Goldfish PIC driver
From: Aleksandar Markovic @ 2017-12-15 16:48 UTC (permalink / raw)
To: linux-mips-6z/3iImG2C8G8FEW9MqTrA
Cc: Miodrag Dinic, Goran Ferenc, Aleksandar Markovic, David S. Miller,
devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Leung,
Greg Kroah-Hartman, James Hogan, Jason Cooper,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Marc Zyngier, Mark Rutland,
Mauro Carvalho Chehab, Paul Burton, Petar Jovanovic,
Raghu Gandham, Randy Dunlap, Rob Herring, Thomas Gleixner
In-Reply-To: <1513356553-7238-1-git-send-email-aleksandar.markovic-FblTVreYubkAvxtiuMwx3w@public.gmane.org>
From: Miodrag Dinic <miodrag.dinic-8NJIiSa5LzA@public.gmane.org>
Add documentation for DT binding of Goldfish PIC driver. The compatible
string used by OS for binding the driver is "google,goldfish-pic".
Signed-off-by: Miodrag Dinic <miodrag.dinic-8NJIiSa5LzA@public.gmane.org>
Signed-off-by: Goran Ferenc <goran.ferenc-8NJIiSa5LzA@public.gmane.org>
Signed-off-by: Aleksandar Markovic <aleksandar.markovic-8NJIiSa5LzA@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../interrupt-controller/google,goldfish-pic.txt | 30 ++++++++++++++++++++++
MAINTAINERS | 5 ++++
2 files changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt
new file mode 100644
index 0000000..35f7527
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt
@@ -0,0 +1,30 @@
+Android Goldfish PIC
+
+Android Goldfish programmable interrupt device used by Android
+emulator.
+
+Required properties:
+
+- compatible : should contain "google,goldfish-pic"
+- reg : <registers mapping>
+- interrupts : <interrupt mapping>
+
+Example for mips when used in cascade mode:
+
+ cpuintc {
+ #interrupt-cells = <0x1>;
+ #address-cells = <0>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ interrupt-controller@1f000000 {
+ compatible = "google,goldfish-pic";
+ reg = <0x1f000000 0x1000>;
+
+ interrupt-controller;
+ #interrupt-cells = <0x1>;
+
+ interrupt-parent = <&cpuintc>;
+ interrupts = <0x2>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 82ad0ea..7620e98 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -867,6 +867,11 @@ S: Supported
F: drivers/android/
F: drivers/staging/android/
+ANDROID GOLDFISH PIC DRIVER
+M: Miodrag Dinic <miodrag.dinic-8NJIiSa5LzA@public.gmane.org>
+S: Supported
+F: Documentation/devicetree/bindings/interrupt-controller/google,goldfish-pic.txt
+
ANDROID GOLDFISH RTC DRIVER
M: Miodrag Dinic <miodrag.dinic-8NJIiSa5LzA@public.gmane.org>
S: Supported
--
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 1/2] dt-bindings: Document mti,mips-cpc binding
From: Aleksandar Markovic @ 2017-12-15 16:51 UTC (permalink / raw)
To: linux-mips
Cc: Paul Burton, Aleksandar Markovic, devicetree, Douglas Leung,
Goran Ferenc, James Hogan, linux-kernel, Mark Rutland,
Miodrag Dinic, Petar Jovanovic, Raghu Gandham, Rob Herring
In-Reply-To: <1513356723-7393-1-git-send-email-aleksandar.markovic@rt-rk.com>
From: Paul Burton <paul.burton@mips.com>
Document a binding for the MIPS Cluster Power Controller (CPC) which
simply allows the device tree to specify where the CPC registers should
be mapped.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Aleksandar Markovic <aleksandar.markovic@mips.com>
---
Documentation/devicetree/bindings/misc/mti,mips-cpc.txt | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/mti,mips-cpc.txt
diff --git a/Documentation/devicetree/bindings/misc/mti,mips-cpc.txt b/Documentation/devicetree/bindings/misc/mti,mips-cpc.txt
new file mode 100644
index 0000000..92eb08f
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/mti,mips-cpc.txt
@@ -0,0 +1,8 @@
+Binding for MIPS Cluster Power Controller (CPC).
+
+This binding allows a system to specify where the CPC registers should be
+mapped using device tree.
+
+Required properties:
+compatible : Should be "mti,mips-cpc".
+regs: Should describe the address & size of the CPC register region.
--
2.7.4
^ permalink raw reply related
* [PATCH v2] arm: kirkwood: dts: Use lower case for bindings notation
From: Mathieu Malaterre @ 2017-12-15 17:07 UTC (permalink / raw)
To: Rob Herring
Cc: Andrew Lunn, Mathieu Malaterre, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215124653.30902-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Improve the DTS files using lower case to fix the following dtc warnings:
Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
Converted using the following command:
find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
For simplicity, two sed expressions were used to solve each warnings separately.
To make the regex expression more robust a few other issues were resolved,
namely setting unit-address to lower case, and adding a whitespace before the
the opening curly brace:
https://elinux.org/Device_Tree_Linux#Linux_conventions
This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
Reported-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Suggested-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
---
v2: Fix the original template message since it was completely misleading for kirkwood subarch.
arch/arm/boot/dts/kirkwood-linksys-viper.dts | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-linksys-viper.dts b/arch/arm/boot/dts/kirkwood-linksys-viper.dts
index df7851820507..f21a50dd9869 100644
--- a/arch/arm/boot/dts/kirkwood-linksys-viper.dts
+++ b/arch/arm/boot/dts/kirkwood-linksys-viper.dts
@@ -157,7 +157,7 @@
reg = <0x80000 0x20000>;
};
- partition@A0000 {
+ partition@a0000 {
label = "s_env";
reg = <0xA0000 0x20000>;
};
@@ -167,17 +167,17 @@
reg = <0x200000 0x2A0000>;
};
- partition@4A0000 {
+ partition@4a0000 {
label = "rootfs";
reg = <0x4A0000 0x1760000>;
};
- partition@1C00000 {
+ partition@1c00000 {
label = "alt_kernel";
reg = <0x1C00000 0x2A0000>;
};
- partition@1EA0000 {
+ partition@1ea0000 {
label = "alt_rootfs";
reg = <0x1EA0000 0x1760000>;
};
@@ -187,7 +187,7 @@
reg = <0x3600000 0x4A00000>;
};
- partition@C0000 {
+ partition@c0000 {
label = "unused";
reg = <0xC0000 0x140000>;
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2] arm: imx: dts: Remove leading 0x and 0s from bindings notation
From: Mathieu Malaterre @ 2017-12-15 17:13 UTC (permalink / raw)
To: Rob Herring
Cc: Fabio Estevam, Mathieu Malaterre, Shawn Guo, Sascha Hauer,
Fabio Estevam, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215124631.30132-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have leading 0s
Converted using the following command:
find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
For simplicity, two sed expressions were used to solve each warnings separately.
To make the regex expression more robust a few other issues were resolved,
namely setting unit-address to lower case, and adding a whitespace before the
the opening curly brace:
https://elinux.org/Device_Tree_Linux#Linux_conventions
This will solve as a side effect warning:
Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
Reported-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Suggested-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
---
v2: Remove invalid patch for imx7s.dtsi, remove duplicate patch for imx7d.dtsi
arch/arm/boot/dts/imx6q-display5.dtsi | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-display5.dtsi b/arch/arm/boot/dts/imx6q-display5.dtsi
index 4084de43d4d9..09085fde3341 100644
--- a/arch/arm/boot/dts/imx6q-display5.dtsi
+++ b/arch/arm/boot/dts/imx6q-display5.dtsi
@@ -255,7 +255,7 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- codec: tfa9879@6C {
+ codec: tfa9879@6c {
#sound-dai-cells = <0>;
compatible = "nxp,tfa9879";
reg = <0x6C>;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 1/8] SOC: brcmstb: add memory API
From: Lorenzo Pieralisi @ 2017-12-15 17:14 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Jim Quinlan, linux-kernel, Bjorn Helgaas, Catalin Marinas,
Will Deacon, Rob Herring, Brian Norris, Russell King,
Robin Murphy, Christoph Hellwig, Florian Fainelli, Jonas Gorski,
Mark Rutland, devicetree, Linux-MIPS, linux-pci, Kevin Cernekee,
Ralf Baechle, bcm-kernel-feedback-list,
Gregory Fong <gregory.0xf0>
In-Reply-To: <20171212211404.GA95453@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Dec 12, 2017 at 03:14:04PM -0600, Bjorn Helgaas wrote:
> [+cc Lorenzo]
>
> On Tue, Dec 12, 2017 at 03:53:28PM -0500, Jim Quinlan wrote:
> > On Tue, Dec 5, 2017 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote:
> > >> From: Florian Fainelli <f.fainelli@gmail.com>
> > >>
> > >> This commit adds a memory API suitable for ascertaining the sizes of
> > >> each of the N memory controllers in a Broadcom STB chip. Its first
> > >> user will be the Broadcom STB PCIe root complex driver, which needs
> > >> to know these sizes to properly set up DMA mappings for inbound
> > >> regions.
> > >>
> > >> We cannot use memblock here or anything like what Linux provides
> > >> because it collapses adjacent regions within a larger block, and here
> > >> we actually need per-memory controller addresses and sizes, which is
> > >> why we resort to manual DT parsing.
> > >>
> > >> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> > >> ---
> > >> drivers/soc/bcm/brcmstb/Makefile | 2 +-
> > >> drivers/soc/bcm/brcmstb/memory.c | 172 +++++++++++++++++++++++++++++++++++++++
> > >> include/soc/brcmstb/memory_api.h | 25 ++++++
> > >> 3 files changed, 198 insertions(+), 1 deletion(-)
> > >> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
> > >> create mode 100644 include/soc/brcmstb/memory_api.h
> > >>
> > >> diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
> > >> index 9120b27..4cea7b6 100644
> > >> --- a/drivers/soc/bcm/brcmstb/Makefile
> > >> +++ b/drivers/soc/bcm/brcmstb/Makefile
> > >> @@ -1 +1 @@
> > >> -obj-y += common.o biuctrl.o
> > >> +obj-y += common.o biuctrl.o memory.o
> > >> diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
> > >> new file mode 100644
> > >> index 0000000..eb647ad9
> > >> --- /dev/null
> > >> +++ b/drivers/soc/bcm/brcmstb/memory.c
> > >
> > > I sort of assume based on [1] that every new file should have an SPDX
> > > identifier ("The Linux kernel requires the precise SPDX identifier in
> > > all source files") and that the actual text of the GPL can be omitted.
> > >
> > > Only a few files in drivers/pci currently have an SPDX identifier. I
> > > don't know if that's oversight or work-in-progress or what.
> > >
> > > [1] https://lkml.kernel.org/r/20171204212120.484179273@linutronix.de
> > >
> >
> > Bjorn, Did you get a chance to review the other commits of this
> > submission (V3)? I would like any additional feedback before I send
> > out a V4 with SPDX fixes. Thanks, JimQ
>
> Lorenzo is taking over drivers/pci/host/* and he'll no doubt have some
> comments when he gets to this. I'll point out a few quick formatting
> things in the meantime.
I need some time to review the code but overall I am quite worried about
patches 1 and 4 in particular, it is ok to have platform host bridge
drivers but we can't rewrite a DMA layer for a specific host bridge, I
really do not like that - it is just not manageable from a maintenance
perspective for the mainline kernel.
Lorenzo
^ permalink raw reply
* [PATCH 0/2] ARM: dts: Some am43x fixes
From: Dave Gerlach @ 2017-12-15 17:16 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Dave Gerlach
Hi,
This series has two fixes for am43x based platforms. First patch disables OPP50
on am437x-idk-evm which the board supply does not support. Second patch is for
am43x-epos-evm and adds dcdc2 regulator as the missing cpu0-supply which
enables CPUFreq on this platform.
Regards,
Dave
Dave Gerlach (2):
ARM: dts: am437x-idk-evm: Disable OPP50 for MPU
ARM: dts: am43x-epos-evm: Hook dcdc2 as the cpu0-supply
arch/arm/boot/dts/am437x-idk-evm.dts | 14 ++++++++++++++
arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++++
2 files changed, 18 insertions(+)
--
2.15.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
* [PATCH 1/2] ARM: dts: am437x-idk-evm: Disable OPP50 for MPU
From: Dave Gerlach @ 2017-12-15 17:16 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Dave Gerlach
In-Reply-To: <20171215171643.8345-1-d-gerlach-l0cyMroinI0@public.gmane.org>
AM437x IDK has a TPS386000 supply voltage supervisor on the VDD_MPU rail
set to trigger undervoltage condition at 0.96V. Because of this, OPP50,
which is normally configured to 300MHz at 0.95V, must be disabled to
avoid triggering the undervoltage condition. Also mark OPP100 as the
suspend-opp as it is now our lowest OPP.
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/am437x-idk-evm.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts b/arch/arm/boot/dts/am437x-idk-evm.dts
index 5e364473067f..20132477a871 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -519,3 +519,17 @@
&cpu {
cpu0-supply = <&tps>;
};
+
+&cpu0_opp_table {
+ /*
+ * Supply voltage supervisor on board will not allow opp50 so
+ * disable it and set opp100 as suspend OPP.
+ */
+ opp50@300000000 {
+ status = "disabled";
+ };
+
+ opp100@600000000 {
+ opp-suspend;
+ };
+};
--
2.15.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
* [PATCH 2/2] ARM: dts: am43x-epos-evm: Hook dcdc2 as the cpu0-supply
From: Dave Gerlach @ 2017-12-15 17:16 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Dave Gerlach
In-Reply-To: <20171215171643.8345-1-d-gerlach-l0cyMroinI0@public.gmane.org>
Hook dcdc2 as the cpu0-supply.
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index a04d79ec212a..1c79c1f8ac07 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -989,3 +989,7 @@
assigned-clocks = <&mux_synctimer32k_ck>;
assigned-clock-parents = <&clkdiv32k_ick>;
};
+
+&cpu {
+ cpu0-supply = <&dcdc2>;
+};
--
2.15.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
* Re: [PATCH v2] arm: imx: dts: Remove leading 0x and 0s from bindings notation
From: Fabio Estevam @ 2017-12-15 17:20 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Rob Herring, Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland,
Russell King, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel
In-Reply-To: <20171215171327.8513-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
HI Mathieu,
On Fri, Dec 15, 2017 at 3:13 PM, Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:
> diff --git a/arch/arm/boot/dts/imx6q-display5.dtsi b/arch/arm/boot/dts/imx6q-display5.dtsi
> index 4084de43d4d9..09085fde3341 100644
> --- a/arch/arm/boot/dts/imx6q-display5.dtsi
> +++ b/arch/arm/boot/dts/imx6q-display5.dtsi
> @@ -255,7 +255,7 @@
> pinctrl-0 = <&pinctrl_i2c1>;
> status = "okay";
>
> - codec: tfa9879@6C {
> + codec: tfa9879@6c {
This change is fine, but it no longer matches the Subject and commit log.
--
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 4/6] dt: bindings: lp8860: Add trigger binding to the lp8860
From: Dan Murphy @ 2017-12-15 17:22 UTC (permalink / raw)
To: Pavel Machek
Cc: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, devicetree,
linux-kernel, linux-leds
In-Reply-To: <20171215090903.GC8221@amd>
Pavel
On 12/15/2017 03:09 AM, Pavel Machek wrote:
> Hi!
>
>> @@ -35,6 +37,7 @@ led-controller@2d {
>> led@0 {
>> reg = <0>;
>> label = "white:display_cluster";
>> + linux,default-trigger = "backlight";
>> };
>> }
>
> What is "display_cluster"? Is it display backlight?
>
This device can be configured to drive all 4 LED strings in display mode
so that all 4 strings have the same brightness controlled either through PWM or
through the brightness register
or
As cluster string where the brightness of individual strings or clustered strings
can be controlled via independent brightness control registers. I am currently working
on adding this support to the driver.
Dan
> Could we use ":backlight" and perhaps start documentation file listing
> "common" LED descriptions so they are shared across machines?
>
> For the record, I'd prefer this to be
> "/sys/class/leds/display:white:backlight" in the end... so that we
> have nice naming for userspace, consistent between different machines.
>
> Pavel
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Doug Anderson @ 2017-12-15 17:29 UTC (permalink / raw)
To: Klaus Goger
Cc: open list:ARM/Rockchip SoC..., Mark Rutland, Heiko Stuebner,
Huibin Hong, Catalin Marinas, Linus Walleij, Will Deacon,
Kever Yang, LKML, Joseph Chen, Romain Perier, Matthias Kaehlcke,
Emil Renner Berthing, Sugar Zhang, Simon Xue, Heinrich Schuchardt,
Brian Norris, Russell King
In-Reply-To: <20171215114427.32059-1-klaus.goger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
Hi,
On Fri, Dec 15, 2017 at 3:44 AM, Klaus Goger
<klaus.goger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org> wrote:
> This patch series replaces all the license text in rockchip devicetree
> files text with a proper SPDX-License-Identifier.
> It follows the guidelines submitted[1] by Thomas Gleixner that are not
> yet merged.
>
> These series also fixes the issue with contradicting statements in most
> licenses. The introduction text claims to be GPL or X11[2] but the
> following verbatim copy of the license is actually a MIT[3] license.
> The X11 license includes a advertise clause and trademark information
> related to the X Consortium. As these X Consortium specfic points are
> irrelevant for us we stick with the actuall license text.
>
> [1] https://patchwork.kernel.org/patch/10091607/
> [2] https://spdx.org/licenses/X11.html
> [3] https://spdx.org/licenses/MIT.html
>
>
> Klaus Goger (2):
> arm64: dts: rockchip: use SPDX-License-Identifier
> ARM: dts: rockchip: use SPDX-License-Identifier
>
> arch/arm/boot/dts/rk3036-evb.dts | 40 +---------------------
> arch/arm/boot/dts/rk3036-kylin.dts | 40 +---------------------
> arch/arm/boot/dts/rk3036.dtsi | 40 +---------------------
> arch/arm/boot/dts/rk3066a-bqcurie2.dts | 39 +--------------------
> arch/arm/boot/dts/rk3066a-marsboard.dts | 39 +--------------------
> arch/arm/boot/dts/rk3066a-mk808.dts | 39 +--------------------
> arch/arm/boot/dts/rk3066a-rayeager.dts | 39 +--------------------
> arch/arm/boot/dts/rk3066a.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk3188-px3-evb.dts | 39 +--------------------
> arch/arm/boot/dts/rk3188-radxarock.dts | 39 +--------------------
> arch/arm/boot/dts/rk3188.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk3228-evb.dts | 40 +---------------------
> arch/arm/boot/dts/rk3229-evb.dts | 40 +---------------------
> arch/arm/boot/dts/rk3229.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk322x.dtsi | 40 +---------------------
> arch/arm/boot/dts/rk3288-evb-act8846.dts | 40 +---------------------
> arch/arm/boot/dts/rk3288-evb-rk808.dts | 40 +---------------------
> arch/arm/boot/dts/rk3288-evb.dtsi | 40 +---------------------
> arch/arm/boot/dts/rk3288-fennec.dts | 40 +---------------------
> arch/arm/boot/dts/rk3288-firefly-beta.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk3288-firefly-reload.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-firefly.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-firefly.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk3288-miqi.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-phycore-rdk.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-phycore-som.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk3288-popmetal.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-r89.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-rock2-som.dtsi | 40 +---------------------
> arch/arm/boot/dts/rk3288-rock2-square.dts | 40 +---------------------
> arch/arm/boot/dts/rk3288-tinker.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi | 5 +--
> arch/arm/boot/dts/rk3288-veyron-brain.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-jaq.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-jerry.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-mickey.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-minnie.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-pinky.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron-speedy.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288-veyron.dtsi | 39 +--------------------
> arch/arm/boot/dts/rk3288-vyasa.dts | 39 +--------------------
> arch/arm/boot/dts/rk3288.dtsi | 40 +---------------------
> arch/arm/boot/dts/rk3xxx.dtsi | 39 +--------------------
> arch/arm/boot/dts/rv1108-evb.dts | 40 +---------------------
> arch/arm/boot/dts/rv1108.dtsi | 40 +---------------------
> arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 39 +--------------------
> .../arm64/boot/dts/rockchip/rk3368-evb-act8846.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 39 +--------------------
> .../boot/dts/rockchip/rk3368-orion-r68-meta.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 39 +--------------------
> .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 39 +--------------------
> .../dts/rockchip/rk3399-sapphire-excavator.dts | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 39 +--------------------
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 +--------------------
> 69 files changed, 69 insertions(+), 2603 deletions(-)
This is just removing the verbatim license text and adding a link to
another file with the text? ...and correcting the name of the
alternate license to be the MIT license... I'm no lawyer, but if
that's what everyone in the kernel agrees is the way they want it
going forward then I have no objections to anything I was involved in.
Thus:
Acked-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 3/7] PCI: tegra: Remove PCI_REASSIGN_ALL_BUS flag for Tegra PCIe
From: Lorenzo Pieralisi @ 2017-12-15 17:36 UTC (permalink / raw)
To: Manikanta Maddireddy, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: cyndis-/1wQRMveznE, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ, vidyas-DDmLM1+adcrQT0dZR+AlfA,
kthota-DDmLM1+adcrQT0dZR+AlfA, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512723493-865-4-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Fri, Dec 08, 2017 at 02:28:09PM +0530, Manikanta Maddireddy wrote:
> Primary, secondary and subordinate default bus numbers are 0 in Tegra and
> it is expecting SW to program these numbers in configration space.
>
> pci_scan_bridge_extend() function programs these numbers in configuration
> space if secondary & subordinate bus numbers are 0 or PCI_REASSIGN_ALL_BUS
> flag is set. Since secondary & subordinate default bus numbers are 0,
> PCI_REASSIGN_ALL_BUS flag can be removed for Tegra PCIe.
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> V3:
> * new patch in V3
> V4:
> * no change in this patch
>
> drivers/pci/host/pci-tegra.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index a549c5899e26..0d91f1a3a6b4 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -2604,7 +2604,6 @@ static int tegra_pcie_probe(struct platform_device *pdev)
>
> tegra_pcie_enable_ports(pcie);
>
> - pci_add_flags(PCI_REASSIGN_ALL_BUS);
This looks obviously OK to me but I need Thierry's ACK to queue it.
Lorenzo
> host->busnr = pcie->busn.start;
> host->dev.parent = &pdev->dev;
> host->ops = &tegra_pcie_ops;
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH net-next v6 2/2] net: ethernet: socionext: add AVE ethernet driver
From: David Miller @ 2017-12-15 17:57 UTC (permalink / raw)
To: hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
masami.hiramatsu-QSEj5FYQhm4dnm+yROfE0A,
jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1513245910-15961-3-git-send-email-hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
From: Kunihiko Hayashi <hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Date: Thu, 14 Dec 2017 19:05:10 +0900
> +static void ave_desc_write(struct net_device *ndev, enum desc_id id,
> + int entry, int offset, u32 val)
> +{
> + struct ave_private *priv = netdev_priv(ndev);
> + u32 addr = (id == AVE_DESCID_TX) ? priv->tx.daddr : priv->rx.daddr;
Please always order local variables from longest to shortest line.
Audit your entire submission for this issue, thank you.
> + ret = register_netdev(ndev);
> + if (ret) {
> + dev_err(dev, "failed to register netdevice\n");
> + goto out_del_napi;
> + }
> +
> + platform_set_drvdata(pdev, ndev);
You must make all software state settings before reigster_netdev() is
invoked.
At the exact moment you call register_netdev(), your device can be
brought up, interrupts processed, PHY state changes made, etc.
So you must put this platform_set_drvdata() before the
register_netdev() call.
Generally speaking, register_netdev() must always be the last state
modification done by your probe routine.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox