* [PATCH v2] mmc: sunxi: Prevent against null dereference for vmmc
From: Chen-Yu Tsai @ 2016-10-21 2:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019133304.22915-1-maxime.ripard@free-electrons.com>
On Wed, Oct 19, 2016 at 9:33 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> VMMC is an optional regulator, which means that mmc_regulator_get_supply
> will only return an error in case of a deferred probe, but not when the
> regulator is not set in the DT.
>
> However, the sunxi driver assumes that VMMC is always there, and doesn't
> check the value of the regulator pointer before using it, which obviously
> leads to a (close to) null pointer dereference.
>
> Add proper checks to prevent that.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 1/6] ARM: sun5i: chip: Enable Wi-Fi SDIO chip
From: Chen-Yu Tsai @ 2016-10-21 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <468cbaad185a2bde92f1015a1c286f1e1ef55850.1476704881.git-series.maxime.ripard@free-electrons.com>
On Mon, Oct 17, 2016 at 7:48 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The WiFi chip is powered through a GPIO and two regulators in parallel.
> Since that case is not supported yet, just set them as always on before we
> rework the regulator framework to deal with those.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 3/6] ARM: sun5i: Rename A10s pins
From: Chen-Yu Tsai @ 2016-10-21 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <926093bcce58496cdb5cea55aaa65e958d36cb76.1476704881.git-series.maxime.ripard@free-electrons.com>
On Mon, Oct 17, 2016 at 7:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The SPI2 pins on the sun5i PB bank are only available on the A10s. Rename
> the A10s only bank so that it doesn't confuse people on the other SoCs
> whose indexing would start at b.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 6/6] ARM: sun5i: chip: Add optional buses
From: Chen-Yu Tsai @ 2016-10-21 2:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54f17420e7532087c4c63db46a282bfc1678d39e.1476704881.git-series.maxime.ripard@free-electrons.com>
On Mon, Oct 17, 2016 at 7:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The I2C1 and SPI2 buses are exposed on the CHIP headers, and are not
> explicitly dedicated to anything.
>
> Add them to the DTS with the muxing already set, but keep them disabled.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
The CHIP docs don't mention SPI2 though.
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Bjorn Helgaas @ 2016-10-21 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a418cf9d-5eeb-a588-6653-fd00e0c2693c@codeaurora.org>
On Thu, Oct 20, 2016 at 01:01:04PM -0700, Sinan Kaya wrote:
> On 10/19/2016 3:44 PM, Bjorn Helgaas wrote:
> > - Maintain a mapping of (IRQ, penalty). Initially all penalties are
> > zero. This is for *all* IRQs, not just ISA ones. This could be a
> > linked list, but the structure is not important as long as we can
> > add things dynamically.
>
> Dynamic allocation doesn't work due to early calls from x86 architecture.
> This is the reason why we iterate the link objects.
Where exactly is this early penalization? That seems to be the
biggest problem. Well, maybe the question of ACPI core parsing of
_CRS/_PRS is a bigger structural problem, but the dynamic allocation
thing at least seems solvable.
^ permalink raw reply
* [PATCH 4/6] ARM: sun5i: Add SPI2 pins
From: Chen-Yu Tsai @ 2016-10-21 2:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a041979c4cc262535d204e6519d8a25fbbc3a94.1476704881.git-series.maxime.ripard@free-electrons.com>
On Mon, Oct 17, 2016 at 7:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> All the sun5i have the SPI2 pins exposed on the PE bank. Add them to the
> DT.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH V4 3/3] Revert "ACPI, PCI, IRQ: separate ISA penalty calculation"
From: Bjorn Helgaas @ 2016-10-21 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476915664-27231-4-git-send-email-okaya@codeaurora.org>
On Wed, Oct 19, 2016 at 06:21:04PM -0400, Sinan Kaya wrote:
> This reverts commit f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty
> calculation") and commit 487cf917ed0d ("revert "ACPI, PCI, IRQ: remove
> redundant code in acpi_irq_penalty_init()"").
>
> Now that we understand the real issue (SCI and ISA penalty getting
> calculated before ACPI start), there is no need for special handling
> for ISA interrupts.
>
> Let's try to simplify the code one more time to share code.
I'm sort of OK with this, but it's not exactly a revert of the above
(the commits you mention don't check "link->irq.initialized == 1".
Previously acpi_irq_penalty_init() looked at _PRS info ("possible"
IRQs), but now we won't. Maybe that's good; I dunno. But it should
be mentioned.
And I don't think it fixes a user-visible problem, so it doesn't need
to be applied immediately. I'm not sure this is worth doing by
itself; maybe it should wait until we can do more cleanup and think
about all these issues together?
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> arch/x86/pci/acpi.c | 1 -
> drivers/acpi/pci_link.c | 44 +++++---------------------------------------
> include/acpi/acpi_drivers.h | 1 -
> 3 files changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 3cd6983..b2a4e2a 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -396,7 +396,6 @@ int __init pci_acpi_init(void)
> return -ENODEV;
>
> printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");
> - acpi_irq_penalty_init();
> pcibios_enable_irq = acpi_pci_irq_enable;
> pcibios_disable_irq = acpi_pci_irq_disable;
> x86_init.pci.init_irq = x86_init_noop;
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 294b190..dd14d78 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -478,7 +478,8 @@ static int acpi_irq_pci_sharing_penalty(int irq)
> * If a link is active, penalize its IRQ heavily
> * so we try to choose a different IRQ.
> */
> - if (link->irq.active && link->irq.active == irq)
> + if ((link->irq.active && link->irq.active == irq) &&
> + (link->irq.initialized == 1))
> penalty += PIRQ_PENALTY_PCI_USING;
>
> /*
> @@ -501,45 +502,10 @@ static int acpi_irq_get_penalty(int irq)
> penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_isa_irq_penalty[irq];
> + penalty += acpi_isa_irq_penalty[irq];
>
> - return penalty + acpi_irq_pci_sharing_penalty(irq);
> -}
> -
> -int __init acpi_irq_penalty_init(void)
> -{
> - struct acpi_pci_link *link;
> - int i;
> -
> - /*
> - * Update penalties to facilitate IRQ balancing.
> - */
> - list_for_each_entry(link, &acpi_link_list, list) {
> -
> - /*
> - * reflect the possible and active irqs in the penalty table --
> - * useful for breaking ties.
> - */
> - if (link->irq.possible_count) {
> - int penalty =
> - PIRQ_PENALTY_PCI_POSSIBLE /
> - link->irq.possible_count;
> -
> - for (i = 0; i < link->irq.possible_count; i++) {
> - if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
> - acpi_isa_irq_penalty[link->irq.
> - possible[i]] +=
> - penalty;
> - }
> -
> - } else if (link->irq.active &&
> - (link->irq.active < ACPI_MAX_ISA_IRQS)) {
> - acpi_isa_irq_penalty[link->irq.active] +=
> - PIRQ_PENALTY_PCI_POSSIBLE;
> - }
> - }
> -
> - return 0;
> + penalty += acpi_irq_pci_sharing_penalty(irq);
> + return penalty;
> }
>
> static int acpi_irq_balance = -1; /* 0: static, 1: balance */
> diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> index 29c6912..797ae2e 100644
> --- a/include/acpi/acpi_drivers.h
> +++ b/include/acpi/acpi_drivers.h
> @@ -78,7 +78,6 @@
>
> /* ACPI PCI Interrupt Link (pci_link.c) */
>
> -int acpi_irq_penalty_init(void);
> int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int *triggering,
> int *polarity, char **name);
> int acpi_pci_link_free_irq(acpi_handle handle);
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy
From: Peter Chen @ 2016-10-21 2:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147700563857.2550.16732518381302920183@sboyd-linaro>
On Thu, Oct 20, 2016 at 04:20:38PM -0700, Stephen Boyd wrote:
> Quoting Stephen Boyd (2016-10-17 18:56:36)
> > +
> > +static int
> > +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> > + void *ptr)
> > +{
> > + struct qcom_usb_hs_phy *uphy;
> > + int is_host;
> > + u8 addr;
> > +
> > + uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> > + is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
>
> Please don't apply this patch. This call now deadlocks on v4.9-rc1
> because of how extcon_get_cable_state_() now grabs a lock that is
> already held here when we're inside the notifier. It's not really
> required that we grab the lock in extcon there, but this has exposed a
> flaw in the logic anyway. We don't know if the id pin is going to toggle
> before or after this function is called, so we should really keep track
> of both vbus and id state in this driver and then do the same ulpi
> writes from two different notifiers for both vbus and id pin. We would
> be duplicating work sometimes, but that's pretty much the best solution
> I can come up with. Otherwise it's racy.
>
Why you need to care id status? If EXTCON_USB event has happened, and
event is true, you can set, otherwise, it is clear operation, that's
to say you may not need have id extcon phandle, do you think so?
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
From: Peter Chen @ 2016-10-21 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147699579088.21058.4379586947317571921@sboyd-linaro>
On Thu, Oct 20, 2016 at 01:36:30PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-20 03:10:18)
> > On Wed, Oct 19, 2016 at 11:55:29PM -0700, Stephen Boyd wrote:
> > > Quoting Peter Chen (2016-10-19 01:02:11)
> > > > On Tue, Oct 18, 2016 at 06:53:07PM -0700, Stephen Boyd wrote:
> > > > > If you're asking if I've made modifications to extcon-usb-gpio, then the
> > > > > answer is no. The branch on linaro.org git server from the cover-letter
> > > > > is the branch I've used to test this with. This patch is specifically to
> > > > > fix issues with that design on the db410c board that has only one pin
> > > > > for ID and vbus detection. It's the schematic that we've discussed in
> > > > > another thread.
> > > > >
> > > > > extcon-usb-gpio sends two extcon events, EXTCON_USB_HOST (for the id
> > > > > pin) and EXTCON_USB (for the vbus). So afaik it does support vbus
> > > > > events.
> > > > >
> > > >
> > > > Hmm, in fact, your ID event is the same with vbus event, you take
> > > > external vbus event as ID event for extcon-usb-gpio handling. Yes,
> > > > it can work due to it sends EXTCON_USB_HOST event first.
> > > >
> > > > Where you change the USB_SW_SEL_PM pin?
> > >
> > > Currently that is done with the mux driver I sent based on the extcon
> > > event. We don't know if that's before or after the controller handles
> > > the extcon event though, so the pin should probably be changed from the
> > > chipidea driver instead to be more explicit. Why do you ask though?
> >
> > I was just curious how you handle it, now I am clear. From my point,
> > the suitable way may be: mux driver + user app (echo role through
> > debugfs). The extcon-usb-gpio is not necessary, since you have already
> > known role at mux driver.
> >
> > The current kernel has no framework to handle dual-role switch at kernel
> > space.
>
> Ok. I'm planning that as future work after this set of patches is
> merged.
>
> > > > @@ -1963,6 +1963,8 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci)
> > > > /* Clear and enable BSV irq */
> > > > hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
> > > > OTGSC_BSVIS | OTGSC_BSVIE);
> > > > + /* vbus change may has already been occurred */
> > >
> > > "vbus change may have already occurred"?
> >
> > Yes, will change.
> >
>
> Great. Should I wait to incorporate your change into my series, or will
> you apply the usb patches and Kishon can apply the phy patches? This
> patch #11 should be dropped, but otherwise I don't think there's
> anything left to do for this series.
I tested my patch, it works well at my side, if it is ok for you, please
ack it, I will apply it as well as your chipidea series after your
gpu fix patch at greg's usb-next tree.
Is it ok for you?
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Bjorn Helgaas @ 2016-10-21 1:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476915664-27231-3-git-send-email-okaya@codeaurora.org>
On Wed, Oct 19, 2016 at 06:21:03PM -0400, Sinan Kaya wrote:
> The SCI penalize function was removed in two steps (first refactor
> and then remove) and these changes are reverted here in one go.
>
> The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> refactored the original code so that SCI penalty is calculated dynamically
> by the time get_penalty function is called. That change is partially
> reverted here, specifically for the SCI IRQ alone.
>
> The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
> ("ACPI,PCI,IRQ: remove SCI penalize function") that replaced the old SCI
> penalty API with penalty calculation carried out dynamically and based
> on the acpi_gbl_FADT.sci_interrupt value.
>
> However, that new algorithm relies on the accurate setting of IRQ
> types and that doesn't happen early enough on some platforms which
> leads to incorrect penalty assignments for PCI IRQs. In those cases,
> irq_get_trigger_type() returns incorrect values for the IRQs in
> question, because they have not been registered yet by the time the
> penalties are calculated.
>
> To fix this problem, we only need to fix the penalty for the SCI interrupt.
> It seems better to add a single "sci_penalty" variable, set it to
> PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
> otherwise, and add "sci_penalty" in when appropriate. That should fix it
> for *any* SCI IRQ, not just those less than 256, and we don't have to add
> these extra penalty table entries that are all unused (except possibly for
> one entry if we have an SCI in the 16-255 range).
>
> For this reason, revert commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI
> penalize function") completely to restore the correct behavior.
I like this patch fine, except for the changelog. I don't think it's
useful to describe this as a revert and give all the historical
details. I think the important part is something like this:
We previously used irq_get_trigger_type(irq) to help compute the
penalty for the SCI, but that depends on the SCI having been
registered already. Add acpi_penalize_sci_irq() so platforms can
tell us the SCI IRQ, trigger, and polarity so we can compute the
penalty even before the SCI has been registered.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://lkml.org/lkml/2016/10/4/283
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Fixes: commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> Fixes: commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function")
"commit" is redundant; it's sufficient to say:
Fixes: 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
In fact, I don't think you really need to include "commit" in the
reference to 9e5ed6d1fb87 above either.
> ---
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 30 +++++++++++++++---------------
> include/linux/acpi.h | 1 +
> 3 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> + acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
> * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 4f37938..294b190 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -87,6 +87,7 @@ struct acpi_pci_link {
>
> static LIST_HEAD(acpi_link_list);
> static DEFINE_MUTEX(acpi_link_lock);
> +static int sci_irq = -1, sci_penalty;
>
> /* --------------------------------------------------------------------------
> PCI Link Device Management
> @@ -496,25 +497,13 @@ static int acpi_irq_get_penalty(int irq)
> {
> int penalty = 0;
>
> - /*
> - * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> - * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> - * use for PCI IRQs.
> - */
> - if (irq == acpi_gbl_FADT.sci_interrupt) {
> - u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> - if (type != IRQ_TYPE_LEVEL_LOW)
> - penalty += PIRQ_PENALTY_ISA_ALWAYS;
> - else
> - penalty += PIRQ_PENALTY_PCI_USING;
> - }
> + if (irq == sci_irq)
> + penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> return penalty + acpi_isa_irq_penalty[irq];
>
> - penalty += acpi_irq_pci_sharing_penalty(irq);
> - return penalty;
> + return penalty + acpi_irq_pci_sharing_penalty(irq);
> }
>
> int __init acpi_irq_penalty_init(void)
> @@ -881,6 +870,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> + sci_irq = irq;
> +
> + if (trigger == ACPI_MADT_TRIGGER_LEVEL &&
> + polarity == ACPI_MADT_POLARITY_ACTIVE_LOW)
> + sci_penalty = PIRQ_PENALTY_PCI_USING;
> + else
> + sci_penalty = PIRQ_PENALTY_ISA_ALWAYS;
> +}
> +
> /*
> * Over-ride default table to reserve additional IRQs for use by ISA
> * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5eaf2f..67d1d3e 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
> int acpi_pci_irq_enable (struct pci_dev *dev);
> void acpi_penalize_isa_irq(int irq, int active);
> bool acpi_isa_irq_available(int irq);
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
> void acpi_pci_irq_disable (struct pci_dev *dev);
>
> extern int ec_read(u8 addr, u8 *val);
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC
From: Jiancheng Xue @ 2016-10-21 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020174805.GA26139@codeaurora.org>
? 2016/10/21 1:48, Stephen Boyd ??:
> On 10/19, Jiancheng Xue wrote:
>>
>> I'm pretty sure that the patch was sent to the DT list devicetree at vger.kernel.org.
>> You had asked a question about "hi3798cv200-sysctrl" and I replied (https://lkml.org/lkml/2016/10/10/517).
>> I'm waiting for your new comments. If there's some misunderstatnding, please let me know.
>>
>
> Are there two patch series that touch the same clk binding
> document? Can you please combine them and resend them if that's
> the case?
>
OK. I will resend this patch.
Thanks,
Jiancheng
^ permalink raw reply
* [PATCH V4 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Bjorn Helgaas @ 2016-10-21 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476915664-27231-2-git-send-email-okaya@codeaurora.org>
On Wed, Oct 19, 2016 at 06:21:02PM -0400, Sinan Kaya wrote:
> The penalty determination of ISA IRQ goes through 4 paths.
> 1. assign PCI_USING during power up via acpi_irq_penalty_init.
> 2. update the penalty with acpi_penalize_isa_irq function based on the
> active parameter.
> 3. kernel command line penalty update via acpi_irq_penalty_update function.
> 4. increment the penalty as USING right after the IRQ is assign to PCI.
>
> acpi_penalize_isa_irq and acpi_irq_penalty_update functions get called
> before the ACPI subsystem is started.
>
> These API need to bypass the acpi_irq_get_penalty function.
I don't mind this patch, but the changelog doesn't tell me what's
broken and why we need this fix. Apparently acpi_irq_get_penalty()
doesn't work before ACPI is initialized, but I don't see *why* it
wouldn't work.
However, I see one bug it *does* fix: we do not store the SCI penalty
in the acpi_isa_irq_penalty[] table because acpi_isa_irq_penalty[]
only holds ISA IRQ penalties, and there's no guarantee that the SCI is
an ISA IRQ. But prior to this patch, we added in the SCI penalty to
the acpi_isa_irq_penalty[] entry when the SCI was an ISA IRQ, which
makes acpi_irq_get_penalty() return the wrong thing. Consider:
Initially acpi_isa_irq_penalty[9] = 0.
Assume sci_interrupt = 9.
Then acpi_irq_get_penalty(9) returns X.
If we call acpi_penalize_isa_irq(9, 1),
it sets acpi_isa_irq_penalty[9] = X,
and now acpi_irq_get_penalty(9) returns X + X.
I'd propose a changelog like this:
We do not want to store the SCI penalty in the acpi_isa_irq_penalty[]
table because acpi_isa_irq_penalty[] only holds ISA IRQ penalties and
there's no guarantee that the SCI is an ISA IRQ. We add in the SCI
penalty as a special case in acpi_irq_get_penalty().
But if we called acpi_penalize_isa_irq() or acpi_irq_penalty_update()
for an SCI that happened to be an ISA IRQ, they stored the SCI
penalty (part of the acpi_irq_get_penalty() return value) in
acpi_isa_irq_penalty[]. Subsequent calls to acpi_irq_get_penalty()
returned a penalty that included *two* SCI penalties.
If this actually fixes a worse problem related to ACPI initialization,
of course you should detail that.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..4f37938 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -849,7 +849,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> continue;
>
> if (used)
> - new_penalty = acpi_irq_get_penalty(irq) +
> + new_penalty = acpi_isa_irq_penalty[irq] +
> PIRQ_PENALTY_ISA_USED;
> else
> new_penalty = 0;
> @@ -871,7 +871,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> void acpi_penalize_isa_irq(int irq, int active)
> {
> if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> - acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + acpi_isa_irq_penalty[irq] = acpi_isa_irq_penalty[irq] +
> (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> }
>
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 0/5] ARM: dts: imx6q: Add Engicam i.CoreM6 dts
From: Shawn Guo @ 2016-10-21 1:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6G_RQyLtgJw=djPTmY5t7UVwzuZpj0xM0HjchLQjq7P5hMOg@mail.gmail.com>
On Tue, Oct 18, 2016 at 05:30:28PM +0530, Jagan Teki wrote:
> Hi Shawn,
>
> On Fri, Oct 14, 2016 at 2:57 PM, Jagan Teki <jteki@openedev.com> wrote:
> > This is series add dts support for Engicam I.Core M6 qdl modules. just
> > rebased on top of linux-next of previous set[1].
> >
> > [1] http://www.spinics.net/lists/kernel/msg2358233.html
> >
> > Jagan Teki (5):
> > ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
> > ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
> > ARM: dts: imx6qdl-icore: Add usbhost support
> > ARM: dts: imx6qdl-icore: Add usbotg support
> > ARM: dts: imx6qdl-icore: Add FEC support
> >
> > arch/arm/boot/dts/Makefile | 2 +
> > arch/arm/boot/dts/imx6dl-icore.dts | 59 ++++++++
> > arch/arm/boot/dts/imx6q-icore.dts | 59 ++++++++
> > arch/arm/boot/dts/imx6qdl-icore.dtsi | 271 +++++++++++++++++++++++++++++++++++
> > 4 files changed, 391 insertions(+)
> > create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
> > create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
> > create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
>
> Can you pick this series?
Sorry for the delay. The first two patches look good, and I had a
couple of small comments on the other 3. Also, for the initial board
support submission like this, you do not need to split it per device
support. That said, please squash the series into one patch when
resending.
Shawn
^ permalink raw reply
* [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic PM domains
From: Lina Iyer @ 2016-10-21 1:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0iKuSWr8xVha7HZ764z+Xk_urP1XFVV-VZ5+JQTuSj-bw@mail.gmail.com>
On Fri, Oct 21 2016 at 16:48 -0600, Rafael J. Wysocki wrote:
>On Fri, Oct 21, 2016 at 12:44 AM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> On Mon, Oct 17 2016 at 01:30 -0600, Ulf Hansson wrote:
>>>
>>> On 14 October 2016 at 19:47, Lina Iyer <lina.iyer@linaro.org> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Changes since v2 [3] -
>>>> - Addressed review comments from v2.
>>>> - domain-idle-states documentation updated
>>>> - fixed compiler issues with imx driver
>>>> - minor code change in pm_domains.c
>>>> - The series is available at [4].
>>>>
>>>> Changes since v1 [2] -
>>>> - Addressed review comments from v1.
>>>> - Fixes around dynamic allocation of genpd states
>>>> - Used OF method for iterating phandles
>>>> - Updated documentation, examples
>>>> - Rename state variable (provider -> fwnode)
>>>> - The series is available at [3].
>>>>
>>>> The changes from [1] are -
>>>> - Allocating memory for domain idle states dynamically
>>>> - Conform to naming conventions for internal and exported genpd functions
>>>> - DT binding example for domain-idle-state
>>>> - Use fwnode instead of of_node
>>>> - Handle atomic case for removal of PM Domain
>>>> - Rebase on top of Rafael's pm/genpd tree
>>>>
>>>> Thanks,
>>>> Lina
>>>>
>>>> Lina Iyer (8):
>>>> PM / Domains: Make genpd state allocation dynamic
>>>> PM / Domain: Add residency property to genpd states
>>>> PM / Domains: Allow domain power states to be read from DT
>>>> PM / Domains: Save the fwnode in genpd_power_state
>>>> dt/bindings: Update binding for PM domain idle states
>>>> PM / Domains: Abstract genpd locking
>>>> PM / Domains: Support IRQ safe PM domains
>>>> PM / doc: Update device documentation for devices in IRQ safe PM
>>>> domains
>>>>
>>>> .../devicetree/bindings/power/power_domain.txt | 43 +++
>>>> Documentation/power/devices.txt | 9 +-
>>>> arch/arm/mach-imx/gpc.c | 17 +-
>>>> drivers/base/power/domain.c | 358
>>>> +++++++++++++++++----
>>>> include/linux/pm_domain.h | 28 +-
>>>> 5 files changed, 383 insertions(+), 72 deletions(-)
>>>>
>>>
>>> Rafael, Lina,
>>>
>>> This looks good to me! Unless any other objections, I suggest to apply
>>> this to get it tested in linux-next.
>>>
>>> Kind regards
>>> Uffe
>>>
>> Rafael,
>>
>> If there are no objections, could you pick this patch for linux-next?
>
>It is in my queue, but not at the top yet.
>
Thank you Rafael.
-- Lina
>Thanks,
>Rafael
^ permalink raw reply
* [PATCH v7 5/5] ARM: dts: imx6qdl-icore: Add FEC support
From: Shawn Guo @ 2016-10-21 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437243-13297-6-git-send-email-jteki@openedev.com>
On Fri, Oct 14, 2016 at 02:57:23PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Add FEC support for Engicam i.CoreM6 dql modules.
>
> Observed similar 'eth0: link is not ready' issue which was
> discussed in [1] due rmii mode with external ref_clk, so added
> clock node along with the properties mentioned by Shawn in [2]
>
> FEC link log:
> ------------
> $ ifconfig eth0 up
> [ 27.905187] SMSC LAN8710/LAN8720 2188000.ethernet:00: attached PHY driver
> [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1)
> [ 27.918982] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>
> [1] https://patchwork.kernel.org/patch/3491061/
> [2] https://patchwork.kernel.org/patch/3490511/
>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v7:
> - none
> Changes for v6:
> - none
> Changes for v5:
> - new patch
>
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 37 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> index 4e79858..972f48f 100644
> --- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> @@ -48,6 +48,18 @@
> reg = <0x10000000 0x80000000>;
> };
>
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
DT maintainers do not like this container node. So please, just like
fix regulator node, put the fixed clock directly under root and give the
node an unique name like clock-xxx.
> +
> + rmii_clk: clock at 0 {
> + compatible = "fixed-clock";
> + reg = <0>;
> + #clock-cells = <0>;
> + clock-frequency = <25000000>; /* 25MHz for example */
> + };
> + };
> +
> reg_3p3v: regulator-3p3v {
> compatible = "regulator-fixed";
> regulator-name = "3P3V";
> @@ -93,6 +105,15 @@
> assigned-clock-parents = <&clks IMX6QDL_CLK_OSC>;
> };
>
> +&fec {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> + clocks = <&clks 117>, <&clks 117>, <&rmii_clk>;
s/117/IMX6QDL_CLK_ENET
Shawn
> + phy-mode = "rmii";
> + status = "okay";
> +};
> +
> &gpmi {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_gpmi_nand>;
> @@ -150,6 +171,22 @@
> };
>
> &iomuxc {
> + pinctrl_enet: enetgrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b1
> + MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
> + MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_REF_CLK__GPIO1_IO23 0x1b0b0
> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
> + >;
> + };
> +
> pinctrl_flexcan1: flexcan1grp {
> fsl,pins = <
> MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b020
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2] ARM: imx: gpc: Initialize all power domains
From: Fabio Estevam @ 2016-10-21 1:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit 0159ec670763dd ("PM / Domains: Verify the PM domain is present
when adding a provider") the following regression is observed on imx6:
imx-gpc: probe of 20dc000.gpc failed with error -22
The imx-gpc driver probe failure causes several issues such as:
- When booting a kernel built with multi_v7_defconfig a kernel crash is
seen.
- When booting a kernel built with imx_v6_v7_defconfig the Etnaviv GPU
driver is not loaded due to the lack of power domains.
The gpc probe fails because of_genpd_add_provider_onecell() now checks
if all the domains are initialized via pm_genpd_present() function
and it fails because not all the power domains are initialized.
In order to fix this error, initialize all the power domains from
imx_gpc_domains[], not only the imx6q_pu_domain.base one.
Reported-by: Olof's autobooter <build@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/mach-imx/gpc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 0df062d..d0463e9 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -430,7 +430,8 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
return 0;
- pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
+ for (i = 0; i < ARRAY_SIZE(imx_gpc_domains); i++)
+ pm_genpd_init(imx_gpc_domains[i], NULL, false);
return of_genpd_add_provider_onecell(dev->of_node,
&imx_gpc_onecell_data);
--
2.7.4
^ permalink raw reply related
* [PATCH v7 4/5] ARM: dts: imx6qdl-icore: Add usbotg support
From: Shawn Guo @ 2016-10-21 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437243-13297-5-git-send-email-jteki@openedev.com>
On Fri, Oct 14, 2016 at 02:57:22PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Add usbotg support for Engicam i.CoreM6 dql modules.
>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v7:
> - none
> Changes for v6:
> - none
> Changes for v5:
> - none
> Changes for v4:
> - new patch
>
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> index ffec879..4e79858 100644
> --- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> @@ -65,6 +65,15 @@
> regulator-boot-on;
> regulator-always-on;
> };
> +
> + reg_usb_otg_vbus: usb_otg_vbus {
Same as host patch, please fix the node name.
Shawn
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> };
>
> &can1 {
> @@ -124,6 +133,14 @@
> status = "okay";
> };
>
> +&usbotg {
> + vbus-supply = <®_usb_otg_vbus>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbotg>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> &usdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1>;
> @@ -198,6 +215,12 @@
> >;
> };
>
> + pinctrl_usbotg: usbotggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
> + >;
> + };
> +
> pinctrl_usdhc1: usdhc1grp {
> fsl,pins = <
> MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17070
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v7 3/5] ARM: dts: imx6qdl-icore: Add usbhost support
From: Shawn Guo @ 2016-10-21 1:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437243-13297-4-git-send-email-jteki@openedev.com>
On Fri, Oct 14, 2016 at 02:57:21PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Add usbhost support for Engicam i.CoreM6 dql modules.
>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v7:
> - none
> Changes for v6:
> - none
> Changes for v5:
> - none
> Changes for v4:
> - new patch
>
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> index f424cd5..ffec879 100644
> --- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> @@ -56,6 +56,15 @@
> regulator-boot-on;
> regulator-always-on;
> };
> +
> + reg_usb_h1_vbus: usb_h1_vbus {
Hyphen instead of underscore should be used in node name. Also please
name fixed regulator in the following schema:
reg_xxx: regulator-xxx {
...
};
Shawn
> + compatible = "regulator-fixed";
> + regulator-name = "usb_h1_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> };
>
> &can1 {
> @@ -109,6 +118,12 @@
> status = "okay";
> };
>
> +&usbh1 {
> + vbus-supply = <®_usb_h1_vbus>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> &usdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] ARM: imx: gpc: Initialize all power domains
From: Fabio Estevam @ 2016-10-21 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CORjf_86-XBy+STd4sEhcus8y1G4B-n58h3KNyuVyEew@mail.gmail.com>
On Thu, Oct 20, 2016 at 3:29 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Shawn,
>
> On Wed, Oct 19, 2016 at 12:15 PM, Shawn Guo <shawnguo@kernel.org> wrote:
>
>> It's not clear to me why this is only with multi_v7_defconfig, not
>> imx_v6_v7_defconfig. Also, is it a regression or long-standing issue?
>
> Investigated this a bit further and the problem seems to be in the
> power domain driver.
>
> The change below fixes the problem on mx6:
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index e023066..461d03c 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1572,8 +1572,6 @@ int of_genpd_add_provider_onecell(struct device_node *np,
> for (i = 0; i < data->num_domains; i++) {
> if (!data->domains[i])
> continue;
> - if (!pm_genpd_present(data->domains[i]))
> - goto error;
>
> data->domains[i]->provider = &np->fwnode;
> data->domains[i]->has_provider = true;
>
> , will submit this to the power domain folks.
Actually the above change would go against:
Author: Jon Hunter <jonathanh@nvidia.com>
Date: Mon Sep 12 12:01:10 2016 +0100
PM / Domains: Verify the PM domain is present when adding a provider
When a PM domain provider is added, there is currently no way to tell if
any PM domains associated with the provider are present. Naturally, the
PM domain provider should not be registered if the PM domains have not
been added. Nonetheless, verify that the PM domain(s) associated with a
provider are present when registering the PM domain provider.
This change adds a dependency on the function pm_genpd_present() when
CONFIG_PM_GENERIC_DOMAINS_OF is enabled and so ensure this function is
available when CONFIG_PM_GENERIC_DOMAINS_OF selected.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
,so it seems the original patch in this thread is correct.
I will update the commit log and submit a v2.
^ permalink raw reply
* [PATCH] kernel: irq: fix build failure
From: Stephen Rothwell @ 2016-10-21 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1610201454410.5073@nanos>
Hi Thomas,
On Thu, 20 Oct 2016 14:55:45 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 10 Oct 2016, Sudip Mukherjee wrote:
>
> > On Thursday 06 October 2016 11:06 PM, Sudip Mukherjee wrote:
> > > The allmodconfig build of powerpc is failing with the error:
> > > ERROR: ".irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> > >
> > > export the symbol to fix the failure.
> >
> > Hi Thomas,
> > powerpc and arm allmodconfig builds still fails with the same error.
> > Build logs of next-20161010 are at:
> > arm at https://travis-ci.org/sudipm-mukherjee/parport/jobs/166321467
> > powerpc at https://travis-ci.org/sudipm-mukherjee/parport/jobs/166321473
>
> I know. This is under discussion with the driver folks as we are not going
> to blindly export stuff just because someone slapped a irq_set_parent()
> into the code w/o knowing why.
Do we have any idea if a resolution is close. This was first reported
in linux-next in September 14/15. :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Bjorn Helgaas @ 2016-10-21 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0gE8uZ4NfuJVtuzkioJS0TpG2mvgJV3o3j0oM7WsVmh7w@mail.gmail.com>
On Thu, Oct 20, 2016 at 01:17:23AM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 20, 2016 at 12:44 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Oct 18, 2016 at 08:32:44AM -0700, Sinan Kaya wrote:
> >> Sorry, I think I didn't have enough morning coffee.
> >>
> >> Looking at these again and trying to be specific.
> >>
> >> On 10/18/2016 8:20 AM, Sinan Kaya wrote:
> >> > It seems wrong to me that we call acpi_irq_get_penalty() from
> >> >> acpi_irq_penalty_update() and acpi_penalize_isa_irq(). It seems like they
> >> >> should just manipulate acpi_isa_irq_penalty[irq] directly.
> >> >>
> >> >> acpi_irq_penalty_update() is for command-line parameters, so it certainly
> >> >> doesn't need the acpi_irq_pci_sharing_penalty() information (the
> >> >> acpi_link_list should be empty at the time we process the command-line
> >> >> parameters).
> >>
> >> Calling acpi_irq_get_penalty for ISA IRQ is OK as long as it doesn't have
> >> any dynamic IRQ calculation such that acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty.
> >>
> >> If this is broken, then we need special care so that we don't assign
> >> dynamically calcualted sci_penalty back to acpi_isa_irq_penalty[irq]. This
> >> results in returning incorrect penalty as
> >>
> >> acpi_irq_get_penalty = acpi_isa_irq_original_penalty[irq] + 2 * sci_penalty.
> >>
> >> Now that we added sci_penalty into the acpi_irq_get_penalty function,
> >> calling acpi_irq_get_penalty is not correct anymore. This line here needs to
> >> be replaced with acpi_isa_irq_penalty[irq] as you suggested.
> >>
> >> if (used)
> >> new_penalty = acpi_irq_get_penalty(irq) +
> >> PIRQ_PENALTY_ISA_USED;
> >> else
> >> new_penalty = 0;
> >>
> >> acpi_isa_irq_penalty[irq] = new_penalty;
> >>
> >>
> >> >>
> >> >> acpi_penalize_isa_irq() is telling us that a PNP or ACPI device is using
> >> >> the IRQ -- this should modify the IRQ's penalty, but it shouldn't depend on
> >> >> the acpi_irq_pci_sharing_penalty() value at all.
> >> >>
> >>
> >> Same problem here. This line will be broken after the sci_penalty change.
> >>
> >> acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> >> (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> >
> > I think the fragility of this code is an indication that we have a
> > design problem, so I want to step back from the nitty gritty details
> > for a bit and look at the overall design.
> >
> > Let me restate the overall problem: We have a PCI device connected to
> > an interrupt link. The interrupt link can be connected to one of
> > several IRQs, and we want to choose one of those IRQs to minimize IRQ
> > sharing.
> >
> > That means we need information about which IRQs are used.
> > Historically we've started with a compiled-in table of common ISA IRQ
> > usage, and we also collect information about which IRQs are used and
> > which *might* be used. So we have the following inputs:
> >
> > - Compiled-in ISA IRQ usage: the static acpi_isa_irq_penalty[]
> > values. ACPI is *supposed* to tell us about all these usages, so
> > I don't know why we have the table. But it's been there as long
> > as I can remember. The table is probably x86-specific, but we
> > keep it in the supposedly generic pci_link.c.
> >
> > - The "acpi_irq_isa=" and "acpi_irq_pci=" command-line overrides via
> > acpi_irq_pci(). I suppose these are for cases where we can't
> > figure things out automatically. I would resist adding parameters
> > like this today (I would treat the need for them as a bug and look
> > for a fix or a quirk), but we might be stuck with these.
> >
> > - SCI information from the ACPI FADT (acpi_penalize_sci_irq()).
> >
> > - PNPBIOS and PNPACPI device IRQ usage from _CRS and _PRS via
> > acpi_penalize_isa_irq(). This is only for IRQs 0-15, and it does
> > NOT include interrupt link (PNP0C0F) devices because we don't
> > handle them as PNPACPI devices. I think this is related to the
> > fact that PNP0C0F doesn't appear in acpi_pnp_device_ids[].
> >
> > - For non-PNP0C0F, non-PNPACPI devices, we completely ignore IRQ
> > information from _CRS and _PRS. This seems sub-optimal and
> > possibly buggy.
> >
> > - Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS via
> > acpi_irq_penalty_init(). This is only for IRQs 0-15, and we only
> > call this on x86. If _PRS exists, we penalize each possible IRQ.
> > If there's no _PRS but _CRS contains an active IRQ, we penalize
> > it.
> >
> > - Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS when
> > enabling a new link. In acpi_irq_pci_sharing_penalty(), we
> > penalize an IRQ if it appears in _CRS or _PRS of any link device
> > in the system.
> >
> > For IRQs 0-15, this overlaps with the penalization done at
> > boot-time by acpi_irq_penalty_init(): if a device has _PRS, we'll
> > add the "possible" penalty twice (once in acpi_irq_penalty_init()
> > and again in acpi_irq_pci_sharing_penalty()), and the "using"
> > penalty once (in acpi_irq_pci_sharing_penalty()).
> >
> > If a device has no _PRS but has _CRS, the "using" penalty is
> > applied twice (once in once in acpi_irq_penalty_init() and again
> > in acpi_irq_pci_sharing_penalty())
> >
> > I think this whole thing is baroque and grotesque.
>
> While I agree, I also would like the regression introduced here to be
> fixed ASAP.
>
> So do you want me to revert all of the changes made here so far and start over?
You're right, of course. We need to fix the regression first, then
worry about longer-term changes. I don't think we necessarily need to
fix *all* the issues with the current scheme, because most of them
have been there forever and I don't think people are tripping over
them.
Bjorn
^ permalink raw reply
* [PATCH 6/8] pinctrl: aspeed-g4: Capture SuperIO pinmux dependency
From: Andrew Jeffery @ 2016-10-21 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYLDesENtq2cQBrWQeL6NH+mO_N5Z=e9=gsoZSCE85Jag@mail.gmail.com>
Hi Linus,
On Thu, 2016-10-20 at 13:53 +0200, Linus Walleij wrote:
> On Tue, Sep 27, 2016 at 4:50 PM, Andrew Jeffery <andrew@aj.id.au>
> wrote:
>
> >
> > Two LPC-related signals in the AST2400 depend on state in the
> > SuperIO IP
> > block. Use the recently added infrastructure to capture this
> > relationship.
> >
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Patch applied for v4.10.
> (Tell me if I'm applying patches in wrong order or something, and
> I hope this doesn't clash with the fixes.)
Both this patch and 8/8 functionally depend on 5/8. I fetched the
pinctrl tree to poke around but this patch didn't appear in any of the
updated branches, so I'm not sure whether we have the right ordering.
Without it we should hit build failures from missing macro definitions.
Have you had a chance to look over patch 5/8? Joel wasn't keen on its
current form, so I would appreciate your input.
Cheers,
Andrew
>
> Yours,
> Linus Walleij
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161021/07de7adc/attachment.sig>
^ permalink raw reply
* [linux-sunxi] [PATCH v5 3/4] Documentation: devicetree: add vendor prefix for Pine64
From: Jonathan Liu @ 2016-10-21 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73852fb92ac0aeec294dc9883cf235d9fa74a07b.1476986335.git-series.maxime.ripard@free-electrons.com>
On 21 October 2016 at 05:00, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> [Maxime: Change title prefix to match the usual style]
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index f0a48ea78659..4eefd1c3ff16 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -208,7 +208,7 @@ parade Parade Technologies Inc.
> pericom Pericom Technology Inc.
> phytec PHYTEC Messtechnik GmbH
> picochip Picochip Ltd
> -pixcir PIXCIR MICROELECTRONICS Co., Ltd
Why is "pixcir PIXCIR MICROELECTRONICS Co., Ltd" removed?
> +pine64 Pine64
> plathome Plat'Home Co., Ltd.
> plda PLDA
> powervr PowerVR (deprecated, use img)
> --
> git-series 0.8.10
Regards,
Jonathan
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: msm8996: Add SMEM DT nodes
From: Stephen Boyd @ 2016-10-21 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477005139-15564-4-git-send-email-spjoshi@codeaurora.org>
On 10/20, Sarangdhar Joshi wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> Add SMEM and TCSR DT nodes on MSM8996.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 949b096..abc1089 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -164,17 +164,36 @@
>
> };
>
> + tcsr_mutex: hwlock {
> + compatible = "qcom,tcsr-mutex";
> + syscon = <&tcsr_mutex_regs 0 0x1000>;
> + #hwlock-cells = <1>;
> + };
> +
> psci {
> compatible = "arm,psci-1.0";
> method = "smc";
> };
>
> + smem {
> + compatible = "qcom,smem";
> +
> + memory-region = <&smem_mem>;
> +
> + hwlocks = <&tcsr_mutex 3>;
Super nitpick: Is there a reason we have newlines between
everything in this node? This node is the only one that isn't
consistent.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/2] clk: mxs: don't register a clkdev for enet_out
From: Stephen Boyd @ 2016-10-20 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020075840.16406-2-u.kleine-koenig@pengutronix.de>
On 10/20, Uwe Kleine-K?nig wrote:
> The last user is gone in the previous commit. So this can be removed, too.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
I'm fine if this goes through arm-soc if you want to bunch them
together. Otherwise just resend the patch once the ARM side
merges into some -rc1 and we can remove it in the next next
release.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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