* [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver
From: Doug Anderson @ 2018-05-30 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7489cd65fedb8a31488cf8188885759bcd4820ce.1527040878.git.collinsd@codeaurora.org>
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote:
> + * @ever_enabled: Boolean indicating that the regulator has been
> + * explicitly enabled at least once. Voltage
> + * requests should be cached when this flag is not
> + * set.
Do you really need this extra boolean? Can't you just check if
"enabled" is still "-EINVAL"? If it is then you don't pass the
voltage along.
...this would mean that you'd also need to send the voltage vote when
the regulator core tries to disable unused regulators at the end of
bootup, but that should be OK right? If we never touched a regulator
anywhere at probe time and we're about to vote to disable it, we know
there's nobody requiring it to still be on. We can vote for the
voltage now without fear of messing up a vote that the BIOS left in
place.
In theory this should also allow you to assert your vote about the
voltage of a regulator that has never been enabled, which (if I
understand correctly) you consider to be a feature.
---
Other than that comment, everything else here looks good to go if Mark
is good with it. As per the previous threads there are some things
that I don't like a ton, but I feel it is between you and Mark to
decide if you're good with it. A summary of those issues are:
1. I still believe that when we disable a regulator in Linux we should
tell RPMh that we vote for the lowest voltage. ...but if Mark is
happy with the way the driver works now I won't push it.
2. As per my comments in the bindings patch, I still believe that
"qcom,drms-mode-max-microamps" belongs in the core. Again, up to
Mark.
3. As per my comments in the bindings patch, I still believe that
we're just adding lots of noise to the DT most of the time by
specifying both "qcom,regulator-drms-modes" and
"regulator-allowed-modes". Again, up to Mark.
-Doug
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523155617.GN4828@sirena.org.uk>
Hi,
On Wed, May 23, 2018 at 8:56 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote:
>> On Wed, May 23, 2018 at 8:40 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > It's got to be valid to think about the voltage of a disabled regulator
>> > since drivers want to be able make sure that the regulator gets enabled
>> > with a sensible config. With most hardware this is really easy since
>> > you can just look at the status reported by the hardware but the RPM
>> > makes this hard since there's so much write only stuff in there.
>
>> I should be more clear. Certainly it should be valid to set the
>> voltage before enabling it so, as you said, the regulator turns on at
>> the right voltage. I'm saying that it's weird (to me) to expect that
>> setting the voltage for a regulator that a client thinks is disabled
>> will affect any real voltages in the system until the regulator is
>> enabled. In RPMh apparently setting a voltage of a regulator you
>> think is disabled can affect the regulator output if another client
>> (unbeknownst to you) happens to have it enabled.
>
> Yes, that's definitely not what's expected but it's unfortunately what
> the firmware chose to implement so we may well be stuck with it
> unfortunately.
We're not really stuck with it if we do what I was suggesting. I was
suggesting that every time we disable the regulator in Linux we have
Linux vote for the lowest voltage it's comfortable with. Linux keeps
track of the true voltage that the driver wants and will always change
its vote back to that before enabling. Thus (assuming Linux is OK
with 1.2 V - 1.4 V for a rail):
Modem: want 1.3 V and enabled.
=> Modem votes for 1.3 V
=> Modem votes for enabled.
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.3V
=> True output: 1.3V
Linux: want 1.4 V and enabled.
=> Linux votes for 1.4 V
=> Linux votes for enabled
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.4V
=> True output: 1.4V
Linux: want disabled
=> Linux votes for disabled
=> Linux votes for 1.2 V (keeps 1.4 V in local var)
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.3V
=> True output: 1.3V
Linux: want enabled
=> Linux votes for 1.4 V (from local var)
=> Linux votes for enabled
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.4V
=> True output: 1.4V
...but I'll leave it to you if you think this is a big deal. If
you're happy with how David's driver works without my suggestion then
I won't push it.
-Doug
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 5:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d03576cf90f06afb1194301cb41fc31704def1d.1527040878.git.collinsd@codeaurora.org>
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote:
> +========
> +Examples
> +========
> +
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +
> +&apps_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vdd-l7-l12-l14-l15-supply = <&pm8998_s5>;
> +
> + smps2 {
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1100000>;
> + };
> +
> + pm8998_s5: smps5 {
> + regulator-min-microvolt = <1904000>;
> + regulator-max-microvolt = <2040000>;
> + };
> +
> + ldo7 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
> + regulator-allowed-modes =
> + <RPMH_REGULATOR_MODE_LPM
> + RPMH_REGULATOR_MODE_HPM>;
> + regulator-allow-set-load;
> + qcom,regulator-drms-modes =
> + <RPMH_REGULATOR_MODE_LPM
> + RPMH_REGULATOR_MODE_HPM>;
> + qcom,drms-mode-max-microamps = <10000 1000000>;
Things look pretty good to me now. I'm still hesitant about the whole
need to list the modes twice (once using the unordered
"regulator-allowed-modes" and once to match up against the ordered
"qcom,drms-mode-max-microamps"). I'm also still of the opinion that
the whole "drms-mode-max-microamps" ought to be a standard property
(not a qcom specific one) and handled in the regulator core.
However, for both of these things I leave it to the discretion of Mark
to choose what he wants. Thus assuming Mark is OK with these two
things, feel free to add my Reviewed-by.
-Doug
^ permalink raw reply
* linux-next: manual merge of the irqchip tree with the arm-soc tree
From: Olof Johansson @ 2018-05-30 5:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1e7a14d-ea49-fc8e-a95c-2b4257096187@st.com>
Hi,
On Tue, May 29, 2018 at 5:20 AM, Ludovic BARRE <ludovic.barre@st.com> wrote:
>
>
> On 05/29/2018 10:55 AM, Alexandre Torgue wrote:
>>
>>
>>
>> On 05/29/2018 10:39 AM, Marc Zyngier wrote:
>>>
>>> On 29/05/18 09:16, Alexandre Torgue wrote:
>>>>
>>>> Hi Marc
>>>>
>>>> On 05/29/2018 09:47 AM, Marc Zyngier wrote:
>>>>>
>>>>> On 29/05/18 08:41, Alexandre Torgue wrote:
>>>>>>
>>>>>> Hi Stephen
>>>>>>
>>>>>> On 05/29/2018 07:52 AM, Stephen Rothwell wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Today's linux-next merge of the irqchip tree got a conflict in:
>>>>>>>
>>>>>>> arch/arm/boot/dts/stm32mp157c.dtsi
>>>>>>>
>>>>>>> between commit:
>>>>>>>
>>>>>>> 3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to
>>>>>>> stm32mp157c")
>>>>>>>
>>>>>>> from the arm-soc tree and commit:
>>>>>>>
>>>>>>> 5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for
>>>>>>> stm32mp157c")
>>>>>>>
>>>>>>> from the irqchip tree.
>>>>>>>
>>>>>>> I fixed it up (see below) and can carry the fix as necessary. This
>>>>>>> is now fixed as far as linux-next is concerned, but any non trivial
>>>>>>> conflicts should be mentioned to your upstream maintainer when your
>>>>>>> tree
>>>>>>> is submitted for merging. You may also want to consider cooperating
>>>>>>> with the maintainer of the conflicting tree to minimise any
>>>>>>> particularly
>>>>>>> complex conflicts.
>>>>>>>
>>>>>>
>>>>>> Thanks for the fix (I will reorder nodes in a future patch). My
>>>>>> opinion
>>>>>> is that all STM32 DT patches should come through my STM32 tree. It is
>>>>>> my
>>>>>> role to fix this kind of conflicts. I thought it was a common rule
>>>>>> (driver patches go to sub-system maintainer tree and DT to the Machine
>>>>>> maintainer). For incoming next-series which contain DT+driver patches
>>>>>> I
>>>>>> will indicate clearly that I take DT patch. I'm right ?
>>>>>
>>>>> Happy to oblige. Can you make sure you sync up with Ludovic and define
>>>>> what you want to do?
>>>>
>>>>
>>>> Sorry I don't understand your reply. I just say that for series
>>>> containing DT patches + drivers patches, to my point of view it is more
>>>> safe that driver patches are taken by sub-system maintainer (you in this
>>>> case) and that I take DT patches in my tree.
>>>
>>> And I'm happy to let you deal with these patches. I'm just asking you
>>> sync with Ludovic to split the series on whichever boundary you wish to
>>> enforce.
>>
>> ok
>>
>>>
>>>>> In the meantime, I'm dropping the series altogether.
>>>>>
>>>> Why? We could keep it as Stephen fixed the merge issue.
>>>
>>> Well, you seem to have a strong opinion about who deals with what. I'll
>>> let Ludovic repost what you and him decide should go via the irqchip
>>> tree.
>>
>>
>> It's not a "strong" opinion just my point of view and maybe not the good
>> one. I thought that's the way of working was like I explained. If you prefer
>> 2 series (one for driver patches and another one for DT patches) I will be
>> happy with that.
>>
>> Ludovic, what is your opinion ?
>
>
> Hi everybody
>
> For this serie, I think we could keep like that with
> Stephen fix. New stm32 irqchip will be integrated (thanks Marc)
> with no conflict with usb (thanks Stephen).
>
> For next series, we may split driver and DT to avoid misunderstanding.
The general rule that we try to use is to always merge DT through the
arm-soc tree, even if the driver gets merged through the subsystem
tree. There should be no harm in doing this for new drivers (i.e. a
new driver won't regress if the DT update is missing, it just won't
probe/configure). And that way we can keep the conflicts internal to
our tree (ideally to the SoC maintainer tree) and not cause overhead
for other maintainers and Stephen.
So yes, for the future please do not submit the DT updates with the
drivers, or at the very least be very clear when you post them that
you don't want the driver maintainer to apply them.
-Olof
^ permalink raw reply
* linux-next: manual merge of the regulator tree with the arm-soc tree
From: Stephen Rothwell @ 2018-05-30 5:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the regulator tree got a conflict in:
arch/arm/mach-omap1/board-ams-delta.c
between commit:
0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
from the arm-soc tree and commit:
6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
from the regulator tree.
I fixed it up (see below - it may be better done) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/mach-omap1/board-ams-delta.c
index 80f54cb54276,759fa18f6ab4..000000000000
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@@ -203,10 -203,8 +203,10 @@@ static struct resource latch2_resources
},
};
- #define LATCH2_LABEL "latch2"
++#define LATCH2_LABEL "ams-delta-latch2"
+
static struct bgpio_pdata latch2_pdata = {
- .label = "ams-delta-latch2",
+ .label = LATCH2_LABEL,
.base = AMS_DELTA_LATCH2_GPIO_BASE,
.ngpio = AMS_DELTA_LATCH2_NGPIO,
};
@@@ -303,6 -288,16 +302,15 @@@ static struct platform_device modem_nre
},
};
+ static struct gpiod_lookup_table modem_nreset_gpiod_table = {
+ .dev_id = "reg-fixed-voltage",
+ .table = {
- /* The AMS_DELTA_GPIO_PIN_MODEM_NRESET is at offset 12 */
- GPIO_LOOKUP("ams-delta-latch2", 12,
++ GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_MODEM_NRESET,
+ "enable", GPIO_ACTIVE_HIGH),
+ { },
+ },
+ };
+
struct modem_private_data {
struct regulator *regulator;
};
@@@ -658,15 -581,7 +666,15 @@@ static int __init late_init(void
platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
+ /*
+ * As soon as devices have been registered, assign their dev_names
+ * to respective GPIO lookup tables before they are added.
+ */
+ ams_delta_lcd_gpio_table.dev_id = dev_name(&ams_delta_lcd_device.dev);
+ ams_delta_nand_gpio_table.dev_id = dev_name(&ams_delta_nand_device.dev);
+
+ gpiod_add_lookup_tables(late_gpio_tables, ARRAY_SIZE(late_gpio_tables));
-
+ gpiod_add_lookup_table(&modem_nreset_gpiod_table);
err = platform_device_register(&modem_nreset_device);
if (err) {
pr_err("Couldn't register the modem regulator device\n");
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/1b173abe/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces
From: joro at 8bytes.org @ 2018-05-30 4:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527610139.14039.58.camel@hpe.com>
On Tue, May 29, 2018 at 04:10:24PM +0000, Kani, Toshi wrote:
> Can you explain why you think allocating a page here is a major problem?
Because a larger allocation is more likely to fail. And if you fail the
allocation, you also fail to free more pages, which _is_ a problem. So
better avoid any allocations in code paths that are about freeing
memory.
> If we just revert, please apply patch 1/3 first. This patch address the
> BUG_ON issue on PAE. This is a real issue that needs a fix ASAP.
It does not address the problem of dirty page-walk caches on x86-64.
> The page-directory cache issue on x64, which is addressed by patch 3/3,
> is a theoretical issue that I could not hit by putting ioremap() calls
> into a loop for a whole day. Nobody hit this issue, either.
How do you know you didn't hit that issue? It might cause silent data
corruption, which might not be easily detected.
> The simple revert patch Joerg posted a while ago causes
> pmd_free_pte_page() to fail on x64. This causes multiple pmd mappings
> to fall into pte mappings on my test systems. This can be seen as a
> degradation, and I am afraid that it is more harmful than good.
The plain revert just removes all the issues with the dirty TLB that the
original patch introduced and prevents huge mappings from being
established when there have been smaller mappings before. This is not
ideal, but at least its is consistent and does not leak pages and leaves
no dirty TLBs. So this is the easiest and most reliable fix for this
stage in the release process.
Regards,
Joerg
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: Greg Kroah-Hartman @ 2018-05-30 4:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c317ed8-cca3-8862-5f3b-12cf14e4d53b@codeaurora.org>
On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
> On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote:
> > On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
> >> Adding pci=safemode kernel command line parameter to turn off all PCI
> >> Express service driver as well as all optional PCIe features such as LTR,
> >> Extended tags, Relaxed Ordering etc.
> >>
> >> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
> >> reconfigured with by the kernel in case BIOS hands off a broken
> >> configuration.
> >
> > Why not fix the BIOS? That's what sane platforms do :)
> >
> >>
> >> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> >> ---
> >> Documentation/admin-guide/kernel-parameters.txt | 2 ++
> >> drivers/pci/pci.c | 7 +++++++
> >> drivers/pci/pci.h | 2 ++
> >> drivers/pci/pcie/portdrv_core.c | 2 +-
> >> drivers/pci/probe.c | 6 ++++++
> >> 5 files changed, 18 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index 641ec9c..247adbb 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -3153,6 +3153,8 @@
> >> noari do not use PCIe ARI.
> >> noats [PCIE, Intel-IOMMU, AMD-IOMMU]
> >> do not use PCIe ATS (and IOMMU device IOTLB).
> >> + safemode turns of all optinal PCI features. Useful
> >> + for bringup/troubleshooting.
> >
> > s/optinal/optional/ ?
>
> sure.
>
> >
> > And you should explain what exactly in PCI is "optional". Who defines
> > this and where is that list and what can go wrong if those options are
> > not enabled?
>
> Bjorn and I discussed the need for such a "safe" mode feature when you
> want to bring up PCI for a platform. You want to turn off everything as
> a starter and just stick to bare minimum.
>
> I can add a few words describing them. The goal of this option is to keep
> base PCI features with MSI only. Things like PME, AER, ASPM, Extended
> Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode
> is certainly not intended for production environments.
Ok, then you should say that here, or somewhere, so that people know
this. Otherwise people will see that "hey this lets my hardware boot!"
and then never change it :(
> I can taint the kernel as a suggestion.
I would not worry about that.
> I defined minimum as just booting a device and to be able to do DMA traffic
> only with 0 optimization
Ok, again, just document this really well, so that people do not have
questions and start wondering why their devices barely seem to work.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] arm64: mm: mark tramp_pg_dir read-only
From: YaoJun @ 2018-05-30 4:48 UTC (permalink / raw)
To: linux-arm-kernel
To protect against KSMA(Kernel Space Mirroring Attack), make
tramp_pg_dir read-only. The principle of KSMA is to insert a
carefully constructed PGD entry into the translation table.
The type of this entry is block, which maps the kernel text
and its access permissions bits are 01. The user process can
then modify kernel text directly through this mapping. In this
way, an arbitrary write can be converted to multiple arbitrary
writes.
Signed-off-by: YaoJun <yaojun8558363@gmail.com>
---
arch/arm64/mm/mmu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..ac4b22c7e435 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -551,6 +551,10 @@ static int __init map_entry_trampoline(void)
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
prot, pgd_pgtable_alloc, 0);
+ update_mapping_prot(__pa_symbol(tramp_pg_dir),
+ (unsigned long)tramp_pg_dir,
+ PGD_SIZE, PAGE_KERNEL_RO);
+
/* Map both the text and data into the kernel page table */
__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
--
2.17.0
^ permalink raw reply related
* [PATCH] PCI: Add pci=safemode option
From: Sinan Kaya @ 2018-05-30 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530043103.GA19734@kroah.com>
On 5/29/2018 9:31 PM, Greg Kroah-Hartman wrote:
> On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
>> Adding pci=safemode kernel command line parameter to turn off all PCI
>> Express service driver as well as all optional PCIe features such as LTR,
>> Extended tags, Relaxed Ordering etc.
>>
>> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
>> reconfigured with by the kernel in case BIOS hands off a broken
>> configuration.
>
> Why not fix the BIOS? That's what sane platforms do :)
>
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 2 ++
>> drivers/pci/pci.c | 7 +++++++
>> drivers/pci/pci.h | 2 ++
>> drivers/pci/pcie/portdrv_core.c | 2 +-
>> drivers/pci/probe.c | 6 ++++++
>> 5 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 641ec9c..247adbb 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3153,6 +3153,8 @@
>> noari do not use PCIe ARI.
>> noats [PCIE, Intel-IOMMU, AMD-IOMMU]
>> do not use PCIe ATS (and IOMMU device IOTLB).
>> + safemode turns of all optinal PCI features. Useful
>> + for bringup/troubleshooting.
>
> s/optinal/optional/ ?
sure.
>
> And you should explain what exactly in PCI is "optional". Who defines
> this and where is that list and what can go wrong if those options are
> not enabled?
Bjorn and I discussed the need for such a "safe" mode feature when you
want to bring up PCI for a platform. You want to turn off everything as
a starter and just stick to bare minimum.
I can add a few words describing them. The goal of this option is to keep
base PCI features with MSI only. Things like PME, AER, ASPM, Extended
Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode
is certainly not intended for production environments.
I can taint the kernel as a suggestion.
I defined minimum as just booting a device and to be able to do DMA traffic
only with 0 optimization
>
> In looking at your patch, I can't determine that at all, so there's no
> way that someone just looking at this sentence will be able to
> understand.
>
> thanks,
>
> greg k-h
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-30 4:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPcyV=fdRu7oLXHMimSFR9ktJ23uBriswTStkEkAMbTaNw@mail.gmail.com>
On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
> Thanks for the patch.
>
> In case of Exynos, the booting CPU always has these information in DT
> and the booting CPU cannot be changed (chosen by firmware/hardware
> configuration).
But can the booting CPU be offlined ?
If yes, then this is how things are broken right now.
Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert
cpufreq driver and that will try to find these properties in CPU1.
> Therefore there is no real risk of falling although
> for correctness of DT your change makes sense.
>
> It is too late for this cycle for me so I'll pick it up after merge window.
> Alternatively, arm-soc guys can pick it up directly with my tag:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
No worries, you can pick it up later on.
--
viresh
^ permalink raw reply
* [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-05-30 4:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527654876-26716-1-git-send-email-okaya@codeaurora.org>
On 5/29/2018 9:34 PM, Sinan Kaya wrote:
> -int early_pci_allowed(void)
> -{
> - return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
> - PCI_PROBE_CONF1;
> -}
I should have kept this. I'll wait for more feedback before posting the
next rev.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-05-30 4:34 UTC (permalink / raw)
To: linux-arm-kernel
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 --
arch/x86/pci/early.c | 50 -------------------------
drivers/pci/pci.c | 4 ++
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 19 ++++++++++
8 files changed, 25 insertions(+), 66 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index c247612..4459270 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2986,7 +2986,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8 offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..e20d449 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -51,53 +51,3 @@ void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val)
outw(val, 0xcfc + (offset&2));
}
-int early_pci_allowed(void)
-{
- return (pci_probe & (PCI_PROBE_CONF1|PCI_PROBE_NOEARLY)) ==
- PCI_PROBE_CONF1;
-}
-
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0xffffffff)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
- if (func == 0) {
- type = read_pci_config_byte(bus, slot,
- func,
- PCI_HEADER_TYPE);
- if (!(type & 0x80))
- break;
- }
- }
- }
- }
-}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7c03701..ae5a2ae 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,8 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+bool pci_early_dump;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5848,6 +5850,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "earlydump")) {
+ pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
pci_realloc_get_opt(str + 8);
} else if (!strncmp(str, "realloc", 7)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..9c66b7d 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -7,7 +7,7 @@
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
extern const unsigned char pcie_link_speed[];
-
+extern bool pci_early_dump;
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
/* Functions internal to the PCI core code */
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 3840207..b1f068d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1549,6 +1549,22 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
return 0;
}
+static void early_dump_pci_device(struct pci_dev *pdev)
+{
+ u32 value[256 / 4];
+ int i;
+
+ dev_info(&pdev->dev, "pci 0000:%02x:%02x.%d config space:\n",
+ pdev->bus->number, PCI_SLOT(pdev->devfn),
+ PCI_FUNC(pdev->devfn));
+
+ for (i = 0; i < 256; i += 4)
+ pci_read_config_dword(pdev, i, &value[i / 4]);
+
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
+ 256, false);
+}
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -1598,6 +1614,9 @@ int pci_setup_device(struct pci_dev *dev)
pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
dev->vendor, dev->device, dev->hdr_type, dev->class);
+ if (pci_early_dump)
+ early_dump_pci_device(dev);
+
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH] PCI: Add pci=safemode option
From: Greg Kroah-Hartman @ 2018-05-30 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527650389-31575-1-git-send-email-okaya@codeaurora.org>
On Tue, May 29, 2018 at 11:19:41PM -0400, Sinan Kaya wrote:
> Adding pci=safemode kernel command line parameter to turn off all PCI
> Express service driver as well as all optional PCIe features such as LTR,
> Extended tags, Relaxed Ordering etc.
>
> Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
> reconfigured with by the kernel in case BIOS hands off a broken
> configuration.
Why not fix the BIOS? That's what sane platforms do :)
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 ++
> drivers/pci/pci.c | 7 +++++++
> drivers/pci/pci.h | 2 ++
> drivers/pci/pcie/portdrv_core.c | 2 +-
> drivers/pci/probe.c | 6 ++++++
> 5 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 641ec9c..247adbb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3153,6 +3153,8 @@
> noari do not use PCIe ARI.
> noats [PCIE, Intel-IOMMU, AMD-IOMMU]
> do not use PCIe ATS (and IOMMU device IOTLB).
> + safemode turns of all optinal PCI features. Useful
> + for bringup/troubleshooting.
s/optinal/optional/ ?
And you should explain what exactly in PCI is "optional". Who defines
this and where is that list and what can go wrong if those options are
not enabled?
In looking at your patch, I can't determine that at all, so there's no
way that someone just looking at this sentence will be able to
understand.
thanks,
greg k-h
^ permalink raw reply
* Status of aspeed-bmc-opp-firestone (IBM S822LC)
From: Andrew Jeffery @ 2018-05-30 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <287c6a85-65ba-5782-e532-d17d517614f5@molgen.mpg.de>
Hi Paul,
On Wed, 30 May 2018, at 00:23, Paul Menzel wrote:
> Dear Joel, dear Linux folks,
>
>
> We have an IBM S822LC system (Firestone(?)). Building of OpenBMC
> currently fails, as the not everything was ported from dev-4.10 to
> dev-4.13 [1], and therefore a file cannot be found.
>
> Looking at upstream Linux, there are BMCs for Power 8 systems, like
> Palmetto, included.
>
> ```
> $ ls arch/arm/boot/dts/aspeed-bmc-opp-*
> arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
> arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
> ```
>
> Does somebody know, why Firestone was not upstreamed? Is somebody
> working on upstreaming it? If not, do you have scripts to port such
> work? Manually cherry-picking stuff in this case is hard, as there are a
> lot of conflicts.
Firestone was never really maintained. We hacked around with it for a bit, but nothing concrete really came of it. As far as I'm aware, no-one is working on upstreaming it.
Also, I don't think there were any scripts used in the process, so it's going to be some drudge work to get things running.
Sorry that I don't have a more positive answer. Maybe someone else knows better.
Cheers,
Andrew
^ permalink raw reply
* [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Nixiaoming @ 2018-05-30 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529154523.GK17159@arm.com>
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64
When reading the code, I feel it is more appropriate to add macro control here.
-----Original Message-----
From: Will Deacon [mailto:will.deacon at arm.com]
Sent: Tuesday, May 29, 2018 11:45 PM
To: Nixiaoming <nixiaoming@huawei.com>
Cc: catalin.marinas at arm.com; ard.biesheuvel at linaro.org; marc.zyngier at arm.com; james.morse at arm.com; kristina.martsenko at arm.com; steve.capper at arm.com; tglx at linutronix.de; mingo at redhat.com; hpa at zytor.com; akpm at linux-foundation.org; vbabka at suse.cz; mhocko at suse.com; dave.hansen at linux.intel.com; dan.j.williams at intel.com; kirill.shutemov at linux.intel.com; zhang.jia at linux.alibaba.com; schwidefsky at de.ibm.com; heiko.carstens at de.ibm.com; gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; x86 at kernel.org; linux-s390 at vger.kernel.org
Subject: Re: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote:
> mark_rodata_ro is only called by the function mark_readonly when
> CONFIG_STRICT_KERNEL_RWX=y,
> if CONFIG_STRICT_KERNEL_RWX is not set
> a compile warning may be triggered: unused function
How are you achieving this configuration? In our Kconfig we select this
unconditionally.
Will
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: Sinan Kaya @ 2018-05-30 3:19 UTC (permalink / raw)
To: linux-arm-kernel
Adding pci=safemode kernel command line parameter to turn off all PCI
Express service driver as well as all optional PCIe features such as LTR,
Extended tags, Relaxed Ordering etc.
Also setting MPS configuration to PCIE_BUS_SAFE so that MPS and MRRS can be
reconfigured with by the kernel in case BIOS hands off a broken
configuration.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
drivers/pci/pci.c | 7 +++++++
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/portdrv_core.c | 2 +-
drivers/pci/probe.c | 6 ++++++
5 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 641ec9c..247adbb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3153,6 +3153,8 @@
noari do not use PCIe ARI.
noats [PCIE, Intel-IOMMU, AMD-IOMMU]
do not use PCIe ATS (and IOMMU device IOTLB).
+ safemode turns of all optinal PCI features. Useful
+ for bringup/troubleshooting.
pcie_scan_all Scan all possible PCIe devices. Otherwise we
only look for one device below a PCIe downstream
port.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d27f771..11f0282 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, disables most of the optional PCI features */
+bool pci_safe_mode;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5845,6 +5848,10 @@ static int __init pci_setup(char *str)
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
+ } else if (!strncmp(str, "safemode", 8)) {
+ pr_info("PCI: safe mode with minimum features\n");
+ pci_safe_mode = true;
+ pcie_bus_config = PCIE_BUS_SAFE;
} else if (!strncmp(str, "noats", 5)) {
pr_info("PCIe: ATS is disabled\n");
pcie_ats_disabled = true;
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..4517bcd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -8,6 +8,8 @@
extern const unsigned char pcie_link_speed[];
+extern bool pci_safe_mode;
+
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
/* Functions internal to the PCI core code */
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index a5b3b3a..9fe4ed6 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -311,7 +311,7 @@ int pcie_port_device_register(struct pci_dev *dev)
/* Get and check PCI Express port services */
capabilities = get_port_device_capability(dev);
- if (!capabilities)
+ if (!capabilities || pci_safe_mode)
return 0;
pci_set_master(dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 3840207..295b79c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2047,6 +2047,9 @@ static void pci_configure_device(struct pci_dev *dev)
struct hotplug_params hpp;
int ret;
+ if (pci_safe_mode)
+ return;
+
pci_configure_mps(dev);
pci_configure_extended_tags(dev, NULL);
pci_configure_relaxed_ordering(dev);
@@ -2213,6 +2216,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Setup MSI caps & disable MSI/MSI-X interrupts */
pci_msi_setup_pci_dev(dev);
+ if (pci_safe_mode)
+ return;
+
/* Buffers for saving PCIe and PCI-X capabilities */
pci_allocate_cap_save_buffers(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
From: Sinan Kaya @ 2018-05-30 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525221024.GC92995@bhelgaas-glaptop.roam.corp.google.com>
Bjorn,
On 5/25/2018 3:10 PM, Bjorn Helgaas wrote:
> On Fri, May 25, 2018 at 09:30:59AM -0400, Sinan Kaya wrote:
>> On 5/24/2018 2:35 PM, Bjorn Helgaas wrote:
>>> That sounds like a reasonable idea, and it is definitely another can
>>> of worms. I looked briefly at some of the .shutdown() cases:
>>
>> should we throw it into 4.18 and see what happens?
>
> It wouldn't solve this particular problem because hpsa *does* have a
> .shutdown() method. The problem is that it doesn't work -- it's
> supposed to stop DMA and interrupts but it apparently doesn't.
>
> I think we need to fix hpsa first.
>
I don't know if you followed my latest V3 patch but I found a way to put
these two together to reach to an, IMO, more acceptable solution.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] PCI: mediatek: Add system pm support for MT2712
From: honghui.zhang at mediatek.com @ 2018-05-30 2:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Honghui Zhang <honghui.zhang@mediatek.com>
The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
the internel control register will be reset after system resume. The PCIe
link should be re-established and the related control register values should
be re-set after system resume.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
CC: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 82 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index dabf1086..60f98d92 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -132,12 +132,14 @@ struct mtk_pcie_port;
/**
* struct mtk_pcie_soc - differentiate between host generations
* @need_fix_class_id: whether this host's class ID needed to be fixed or not
+ * @pm_support: whether the host's MTCMOS will be off when suspend
* @ops: pointer to configuration access functions
* @startup: pointer to controller setting functions
* @setup_irq: pointer to initialize IRQ functions
*/
struct mtk_pcie_soc {
bool need_fix_class_id;
+ bool pm_support;
struct pci_ops *ops;
int (*startup)(struct mtk_pcie_port *port);
int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
@@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device *pdev)
return err;
}
+static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct mtk_pcie *pcie;
+ struct mtk_pcie_port *port;
+ const struct mtk_pcie_soc *soc;
+
+ pdev = to_platform_device(dev);
+ pcie = platform_get_drvdata(pdev);
+ soc = pcie->soc;
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ clk_disable_unprepare(port->ahb_ck);
+ clk_disable_unprepare(port->sys_ck);
+ phy_power_off(port->phy);
+ }
+
+ return 0;
+}
+
+static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct mtk_pcie *pcie;
+ struct mtk_pcie_port *port;
+ const struct mtk_pcie_soc *soc;
+ int ret;
+
+ pdev = to_platform_device(dev);
+ pcie = platform_get_drvdata(pdev);
+ soc = pcie->soc;
+ if (!soc->pm_support)
+ return 0;
+
+ list_for_each_entry(port, &pcie->ports, list) {
+ ret = phy_power_on(port->phy);
+ if (ret) {
+ dev_err(dev, "could not power on phy\n");
+ return ret;
+ }
+ ret = clk_prepare_enable(port->sys_ck);
+ if (ret) {
+ dev_err(dev, "enable sys clock error\n");
+ phy_power_off(port->phy);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(port->ahb_ck);
+ if (ret) {
+ dev_err(dev, "enable ahb clock error\n");
+ phy_power_off(port->phy);
+ clk_disable_unprepare(port->sys_ck);
+ return ret;
+ }
+
+ ret = soc->startup(port);
+ if (ret) {
+ dev_err(dev, "pcie linkup failed\n");
+ phy_power_off(port->phy);
+ clk_disable_unprepare(port->sys_ck);
+ clk_disable_unprepare(port->ahb_ck);
+ return ret;
+ }
+
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ mtk_pcie_enable_msi(port);
+ }
+
+ return 0;
+}
+
+const struct dev_pm_ops mtk_pcie_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
+ mtk_pcie_resume_noirq)
+};
+
static const struct mtk_pcie_soc mtk_pcie_soc_v1 = {
.ops = &mtk_pcie_ops,
.startup = mtk_pcie_startup_port,
};
static const struct mtk_pcie_soc mtk_pcie_soc_mt2712 = {
+ .pm_support = true,
.ops = &mtk_pcie_ops_v2,
.startup = mtk_pcie_startup_port_v2,
.setup_irq = mtk_pcie_setup_irq,
@@ -1211,6 +1292,7 @@ static struct platform_driver mtk_pcie_driver = {
.name = "mtk-pcie",
.of_match_table = mtk_pcie_ids,
.suppress_bind_attrs = true,
+ .pm = &mtk_pcie_pm_ops,
},
};
builtin_platform_driver(mtk_pcie_driver);
--
2.6.4
^ permalink raw reply related
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Pratyush Anand @ 2018-05-30 2:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpO8KVVD_6ZJTW2SiyR8v0uDMA3H9yKHNw1=RKO+fd7KjA@mail.gmail.com>
Hi Bhupesh,
On Mon, May 28, 2018 at 2:33 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> Hi ARM64 maintainers,
[...]
>
> 4. Since 'memstart_addr' indicates the start of physical RAM, we
> randomize the same on basis of 'memstart_offset_seed' value above.
> Also the 'memstart_addr' value is available in '/proc/kallsyms' and
> hence can be accessed by user-space applications to read the
> 'memstart_addr' value.
User space can read, only when a system has either CONFIG_DEVMEM or
CONFIG_PROC_KCORE enabled. But, we can have a system which has
CONFIG_RANDOMIZE_BASE enabled but none of the kernel memory access
interface (other than kdump/vmcore).
>
> 5. Now since the PAGE_OFFSET value is also used by several user space
> tools (for e.g. makedumpfile tool uses the same to determine the start
> of linear region and hence to read PT_NOTE fields from /proc/kcore), I
> am not sure how to read the randomized value of the same in the KASLR
> enabled case.
>
Do we have a use case other than makedumpfile (I mean where we do not
have vmcore access)? For makedumpfile, we have following information
in vmcore, and I hope, that should be sufficient to find physical
address of any symbol from vmcore.
358 VMCOREINFO_NUMBER(VA_BITS);
359 /* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
360 vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
361 kimage_voffset);
362 vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
363 PHYS_OFFSET);
Regards
Pratyush
^ permalink raw reply
* [PATCH V3 2/2] scsi: hpsa: drop shutdown callback
From: Ryan Finnie @ 2018-05-30 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527542471-10316-2-git-send-email-okaya@codeaurora.org>
On 05/28/2018 02:21 PM, Sinan Kaya wrote:
> 'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during
> shutdown")' has been added to kernel to shutdown pending PCIe port
> service interrupts during reboot so that a newly started kexec kernel
> wouldn't observe pending interrupts.
>
> pcie_port_device_remove() is disabling the root port and switches by
> calling pci_disable_device() after all PCIe service drivers are shutdown.
>
> This has been found to cause crashes on HP DL360 Gen9 machines during
> reboot due to hpsa driver not clearing the bus master bit during the
> shutdown procedure by calling pci_disable_device().
>
> Drop the shutdown API and do an orderly clean up by using the remove.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
> Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
> Cc: stable at vger.kernel.org
> Reported-by: Ryan Finnie <ryan@finnie.org>
Tested successfully on DL360 Gen9 and DL380 Gen9.
Tested-by: Ryan Finnie <ryan@finnie.org>
^ permalink raw reply
* [PATCH V3 1/2] PCI: Try to clean up resources via remove if shutdown doesn't exist
From: Ryan Finnie @ 2018-05-30 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527542471-10316-1-git-send-email-okaya@codeaurora.org>
On 05/28/2018 02:21 PM, Sinan Kaya wrote:
> It is up to a driver to implement shutdown() callback. If shutdown()
> callback is not implemented, PCI device can have pending interrupt and
> even do DMA transactions while the system is going down.
>
> If kexec is in use, this can damage the newly booting kexec kernel
> or even prevent it from booting altogether. Fallback to calling the
> remove() callback if shutdown() isn't implemented for a given driver.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779
> Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")
> Cc: stable at vger.kernel.org
> Reported-by: Ryan Finnie <ryan@finnie.org>
Tested successfully on DL360 Gen9 and DL380 Gen9.
Tested-by: Ryan Finnie <ryan@finnie.org>
^ permalink raw reply
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Anson Huang @ 2018-05-30 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e0690c89b24b4b028e4a0dab63334af4b37fdd3.camel@nxp.com>
Hi, Leonard
Anson Huang
Best Regards!
> -----Original Message-----
> From: Leonard Crestez
> Sent: Tuesday, May 29, 2018 10:03 PM
> To: Anson Huang <anson.huang@nxp.com>; shawnguo at kernel.org; Andrey
> Smirnov <andrew.smirnov@gmail.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; s.hauer at pengutronix.de;
> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>; Abel Vesa
> <abel.vesa@nxp.com>; Richard Liu <xuegang.liu@nxp.com>
> Subject: Re: [PATCH] soc: imx: gpcv2: correct PGC offset
>
> On Tue, 2018-05-29 at 16:02 +0800, Anson Huang wrote:
> > Correct MIPI/PCIe/USB_HSIC's PGC offset based on design RTL, the value
> > on Reference Manual are incorrect.
> >
> > The correct offset should be as below:
> >
> > -#define PGC_MIPI 4
> > -#define PGC_PCIE 5
> > -#define PGC_USB_HSIC 8
> > +#define PGC_MIPI 16
> > +#define PGC_PCIE 17
> > +#define PGC_USB_HSIC 20
> > #define GPC_PGC_CTRL(n) (0x800 + (n) * 0x40)
> > #define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc)
>
> This gpcv2 driver is currently only used for PCI, it probably only works because
> domains happen to be turned on by default?
I think so.
>
> On imx7d upstream platform suspend is not yet supported but even doing
> device-level suspend causes a hang on resume somewhere in PCI on first read.
> This patch fixes that immediate hang.
I just added the imx7d platform suspend/resume support using psci in u-boot, patches
are sent out for review.
I did notice PCI resume cause system hang, the root cause is PCI controller registers
can NOT be accessed after resume, and the PCI PHY PLL is NOT locked when issue happen,
the PCI driver should implement suspend/resume and redo the init flow after resume, since
its power VDD1P0D are OFF after suspend.
I saw you sent out patch to fix it, thanks.
Anson.
>
> After suspend/resume lspci is broken (device doesn't properly resume), that
> probably requires more imx pci patches and unrelated to pgc.
>
> --
> Regards,
> Leonard
^ permalink raw reply
* [PATCH V2] soc: imx: gpcv2: correct PGC offset
From: Anson Huang @ 2018-05-30 1:30 UTC (permalink / raw)
To: linux-arm-kernel
Correct MIPI/PCIe/USB_HSIC's PGC offset based on
design RTL, the values in the Reference Manual
(Rev. 1, 01/2018 and the older ones) are incorrect.
The correct offset values should be as below:
0x800 ~ 0x83F: PGC for core0 of A7 platform;
0x840 ~ 0x87F: PGC for core1 of A7 platform;
0x880 ~ 0x8BF: PGC for SCU of A7 platform;
0xA00 ~ 0xA3F: PGC for fastmix/megamix;
0xC00 ~ 0xC3F: PGC for MIPI PHY;
0xC40 ~ 0xC7F: PGC for PCIe_PHY;
0xC80 ~ 0xCBF: PGC for USB OTG1 PHY;
0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY;
0xD00 ~ 0xD3F: PGC for USB HSIC PHY;
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
changes since V1:
add comment in code to make it more readable;
improve the commit message.
drivers/soc/imx/gpcv2.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index f4e3bd4..6ef18cf 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -39,10 +39,15 @@
#define GPC_M4_PU_PDN_FLG 0x1bc
-
-#define PGC_MIPI 4
-#define PGC_PCIE 5
-#define PGC_USB_HSIC 8
+/*
+ * The PGC offset values in Reference Manual
+ * (Rev. 1, 01/2018 and the older ones) GPC chapter's
+ * GPC_PGC memory map are incorrect, below offset
+ * values are from design RTL.
+ */
+#define PGC_MIPI 16
+#define PGC_PCIE 17
+#define PGC_USB_HSIC 20
#define GPC_PGC_CTRL(n) (0x800 + (n) * 0x40)
#define GPC_PGC_SR(n) (GPC_PGC_CTRL(n) + 0xc)
--
2.7.4
^ permalink raw reply related
* [PATCH] soc: imx: gpcv2: correct PGC offset
From: Anson Huang @ 2018-05-30 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHQ1cqF1-zkR_wQgRK1M3Wd+Hvha+St3jT=-Qvn1RM8N88qW8Q@mail.gmail.com>
Hi, Andrey
Anson Huang
Best Regards!
> -----Original Message-----
> From: Andrey Smirnov [mailto:andrew.smirnov at gmail.com]
> Sent: Wednesday, May 30, 2018 7:11 AM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <s.hauer@pengutronix.de>; Sascha Hauer <kernel@pengutronix.de>; Fabio
> Estevam <fabio.estevam@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel <linux-arm-kernel@lists.infradead.org>; linux-kernel
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH] soc: imx: gpcv2: correct PGC offset
>
> On Tue, May 29, 2018 at 1:02 AM, Anson Huang <Anson.Huang@nxp.com>
> wrote:
> > Correct MIPI/PCIe/USB_HSIC's PGC offset based on design RTL, the value
> > on Reference Manual are incorrect.
> >
>
> Nit: I'd s/the value on/the values in the/ here.
>
> > The correct offset should be as below:
> >
> > 0x800 ~ 0x83F: PGC for core0 of A7 platform;
> > 0x840 ~ 0x87F: PGC for core1 of A7 platform;
> > 0x880 ~ 0x8BF: PGC for SCU of A7 platform;
> > 0xA00 ~ 0xA3F: PGC for fastmix/megamix;
> > 0xC00 ~ 0xC3F: PGC for MIPI PHY;
> > 0xC40 ~ 0xC7F: PGC for PCIe_PHY;
> > 0xC80 ~ 0xCBF: PGC for USB OTG1 PHY;
> > 0xCC0 ~ 0xCFF: PGC for USB OTG2 PHY;
> > 0xD00 ~ 0xD3F: PGC for USB HSIC PHY;
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > drivers/soc/imx/gpcv2.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c index
> > afc7ecc..132c946 100644
> > --- a/drivers/soc/imx/gpcv2.c
> > +++ b/drivers/soc/imx/gpcv2.c
> > @@ -40,9 +40,9 @@
> > #define GPC_M4_PU_PDN_FLG 0x1bc
> >
> >
> > -#define PGC_MIPI 4
> > -#define PGC_PCIE 5
> > -#define PGC_USB_HSIC 8
> > +#define PGC_MIPI 16
> > +#define PGC_PCIE 17
> > +#define PGC_USB_HSIC 20
>
> As a suggestion, please add a comment explicitly saying that those values
> might differ from what some version of the RM might specify.
> Explanation in commit message is great, but seeing a note in the code might
> save quite a bit of digging for someone who is reading the code, double
> checking those values and thinking that they might be wrong.
>
> Other than that:
>
> Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>
> Thanks,
> Andrey Smirnov
Thanks, I will improve them in V2 patch.
Anson.
^ permalink raw reply
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: Andy Shevchenko @ 2018-05-30 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-3-git-send-email-ray.jui@broadcom.com>
On Wed, May 30, 2018 at 12:58 AM, Ray Jui <ray.jui@broadcom.com> wrote:
> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
> INTD share the same interrupt line connected to the GIC in the system,
> while the status of each INTx can be obtained through the INTX CSR
> register
> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
> + SYS_RC_INTX_MASK) != 0) {
> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(dev, "unexpected INTx%u\n", bit);
> + }
> + }
do {
status = ...;
for_each_set_bit() {
...
}
} while (status);
would look slightly better for my opinion.
--
With Best Regards,
Andy Shevchenko
^ 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