[PATCH] ARM: dts: imx6sx-sabreauto: add debug LED support
There is a debug LED(D11) connected to GPIO1_IO24, add
support for it.
Signed-off-by: Anson Huang
---
this patch is based on patch series (ARM: dts: imx6sx-sabreauto: add wdog
external reset support).
arch/arm/boot/dts/imx6sx-sabreauto.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index eb1452c..6b94f24 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -18,6 +18,18 @@
reg = <0x8000 0x8000>;
};
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+
+ user {
+ label = "debug";
+ gpios = <&gpio1 24 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -119,6 +131,12 @@
&iomuxc {
imx6x-sabreauto {
+ pinctrl_led: ledgrp {
+ fsl,pins = <
+ MX6SX_PAD_CSI_PIXCLK__GPIO1_IO_24 0x17059
+ >;
+ };
+
pinctrl_enet1_1: enet1grp-1 {
fsl,pins = <
MX6SX_PAD_ENET1_MDIO__ENET1_MDIO0xa0b1
--
2.7.4
Re: [PATCH v3 1/7] kprobes: Make blacklist root user read only
* Masami Hiramatsu wrote:
> Since the blacklist file indicates a sensitive address
> information to reader, it should be restricted to the
> root user.
>
> Suggested-by: Thomas Richter
> Signed-off-by: Masami Hiramatsu
> ---
> kernel/kprobes.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index ea619021d901..51096eece801 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -2621,7 +2621,7 @@ static int __init debugfs_kprobe_init(void)
> if (!file)
> goto error;
>
> - file = debugfs_create_file("blacklist", 0444, dir, NULL,
> + file = debugfs_create_file("blacklist", 0400, dir, NULL,
> &debugfs_kprobe_blacklist_ops);
> if (!file)
> goto error;
Note that in a typical Linux distro debugfs is already root-only:
fomalhaut:~> ls -ld /sys/kernel/debug
drwx-- 28 root root 0 Apr 23 08:55 /sys/kernel/debug
but this change might make sense if debugfs is mounted in some other fashion.
But the patch looks incomplete, 'blacklist' is not the only word-readable file
in
the kprobes hierarchy. The kprobes directory itself, and the 'list' file is
readable as well:
[root@fomalhaut ~]# ls -ld /sys/kernel/debug/kprobes
drwxr-xr-x 2 root root 0 Apr 23 08:55 /sys/kernel/debug/kprobes
[root@fomalhaut ~]# ls -l /sys/kernel/debug/kprobes/
-r--r--r-- 1 root root 0 Apr 23 08:55 blacklist
-rw--- 1 root root 0 Apr 23 08:55 enabled
-r--r--r-- 1 root root 0 Apr 23 08:55 list
So not just the blacklist should be 400 but 'list' as well, and the main
kprobes
directory as well.
Thanks,
Ingo
Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED
On Fri, Apr 27, 2018 at 08:53:39AM +0200, Lars-Peter Clausen wrote: > On 04/27/2018 07:11 AM, Vinod Koul wrote: > > On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote: > >> Request IRQ with IRQF_SHARED flag. This works since the interrupt > >> handler already checks if there is an actual IRQ pending and returns > >> IRQ_NONE otherwise. > > > > hmmm what are we trying to fix here? Is your device on a shared line or not? > > IRQF_SHARED does not mean that the IRQ is on a shared line. It means that > the driver can handle it if the IRQ is on a shared line. Since the driver > can handle it setting the flag is a good idea since this enables usecases > where the line is shared. Yes that is correct indeed, but what is the motivation for the change. If you never expect this to be in shared environment why to do this? Sorry but "it works" is not a good enough reason for this change, to enable usecases where the line is shared is a good reason :) -- ~Vinod
Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable
On Thu 26-04-18 21:28:18, Michal Hocko wrote: > On Thu 26-04-18 11:19:33, Eric W. Biederman wrote: > > Michal Hocko writes: > > > > > I've had a patch to remove owner few years back. It needed some work > > > to finish but maybe that would be a better than try to make > > > non-scalable thing suck less. > > > > I have a question. Would it be reasonable to just have a mm->memcg? > > That would appear to be the simplest solution to the problem. > > I do not remember details. Have to re-read the whole thing again. Hope > to get to this soon but with the current jet lag and backlog from the > LSFMM I rather not promis anything. Going with mm->memcg would be the > most simple of course but I have a very vague recollection that it was > not possible. Maybe I misremember... Just for the record, the last version where I've tried to remove owner was posted here: http://lkml.kernel.org/r/1436358472-29137-1-git-send-email-mho...@kernel.org I didn't get to remember details yet, but the primary problem was the task migration between cgroups and the nasty case when different thread grounds share the mm. At some point I just suggested to not care about semantic of these weird threads all that much. We can either migrate all tasks sharing the mm struct or just keep the inconsistency. Anyway, removing this ugliness would be so cool! -- Michal Hocko SUSE Labs
Re: [PATCH] mm: sections are not offlined during memory hotremove
On Thu, Apr 26, 2018 at 04:30:02PM -0400, Pavel Tatashin wrote:
> Memory hotplug, and hotremove operate with per-block granularity. If
> machine has large amount of memory (more than 64G), the size of memory
> block can span multiple sections. By mistake, during hotremove we set
> only the first section to offline state.
>
> The bug was discovered because kernel selftest started to fail:
> https://lkml.kernel.org/r/20180423011247.GK5563@yexl-desktop
>
> After commit, "mm/memory_hotplug: optimize probe routine". But, the bug is
> older than this commit. In this optimization we also added a check for
> sections to be in a proper state during hotplug operation.
>
> Fixes: 2d070eab2e82 ("mm: consider zone which is not fully populated to have
> holes")
>
> Signed-off-by: Pavel Tatashin
> Acked-by: Michal Hocko
> ---
> mm/sparse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 62eef264a7bd..73dc2fcc0eab 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -629,7 +629,7 @@ void offline_mem_sections(unsigned long start_pfn,
> unsigned long end_pfn)
> unsigned long pfn;
>
> for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> - unsigned long section_nr = pfn_to_section_nr(start_pfn);
> + unsigned long section_nr = pfn_to_section_nr(pfn);
> struct mem_section *ms;
>
> /*
> --
> 2.17.0
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH 00/24] device link, bridge supplier <-> drm device
Hi Peter, On 27.04.2018 00:31, Peter Rosin wrote: > Hi! > > It was noted by Russel King [1] that bridges (not using components) > might disappear unexpectedly if the owner of the bridge was unbound. > Jyri Sarha had previously noted the same thing with panels [2]. Jyri > came up with using device links to resolve the panel issue, which > was also my (independent) reaction to the note from Russel. > > This series builds up to the addition of that link in the last > patch, but in my opinion the other 23 patches do have merit on their > own. > > The last patch needs testing, while the others look trivial. That > said, I might have missed some subtlety. of_node is used as an identifier of the bridge in the kernel. If you replace it with device pointer there will be potential problem with devices having two or more bridges, how do you differentiate bridges if the owner is the same? If I remember correctly current bridge code does not allow to have multiple bridges in one device, but that should be quite easy to fix if necessary. After this change it will become more difficult. Anyway I remember discussion that in DT world bridge should be identified rather by of_graph port node, not by parent node as it is now. If you want to translate this relation to device owner, you should add also port number to have full identification of the bridge, ie pair (owner, port_number) would be equivalent of port node. Regards Andrzej > > Cheers, > Peter > > [1] https://lkml.org/lkml/2018/4/23/769 > [2] https://www.spinics.net/lists/dri-devel/msg174275.html > > Peter Rosin (24): > drm/bridge: allow optionally specifying an .owner device > drm/bridge: adv7511: provide an .owner device > drm/bridge/analogix: core: specify the .owner of the bridge > drm/bridge: analogix-anx78xx: provide an .owner device > drm/bridge: vga-dac: provide an .owner device > drm/bridge: lvds-encoder: provide an .owner device > drm/bridge: megachips-stdp-ge-b850v3-fw: provide an .owner device > drm/bridge: nxp-ptn3460: provide an .owner device > drm/bridge: panel: provide an .owner device > drm/bridge: ps8622: provide an .owner device > drm/bridge: sii902x: provide an .owner device > drm/bridge: sii9234: provide an .owner device > drm/bridge: sii8620: provide an .owner device > drm/bridge: synopsys: provide an .owner device for the bridges > drm/bridge: tc358767: provide an .owner device > drm/bridge: ti-tfp410: provide an .owner device > drm/exynos: mic: provide an .owner device for the bridge > drm/mediatek: hdmi: provide an .owner device for the bridge > drm/msm: specify the .owner of the bridges > drm/rcar-du: lvds: provide an .owner device for the bridge > drm/sti: provide an .owner device for the bridges > drm/bridge: remove the .of_node member > drm/bridge: require the .owner to be filled in on drm_bridge_attach > drm/bridge: establish a link between the bridge supplier and consumer > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 + > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > drivers/gpu/drm/bridge/lvds-encoder.c | 2 +- > .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > drivers/gpu/drm/bridge/panel.c | 4 +--- > drivers/gpu/drm/bridge/parade-ps8622.c | 2 +- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/sii9234.c | 2 +- > drivers/gpu/drm/bridge/sil-sii8620.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +--- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +--- > drivers/gpu/drm/bridge/tc358767.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c | 2 +- > drivers/gpu/drm/drm_bridge.c | 23 > +- > drivers/gpu/drm/exynos/exynos_drm_mic.c| 2 +- > drivers/gpu/drm/mediatek/mtk_hdmi.c| 2 +- > drivers/gpu/drm/msm/dsi/dsi_manager.c | 1 + > drivers/gpu/drm/msm/edp/edp_bridge.c | 1 + > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 + > drivers/gpu/drm/rcar-du/rcar_lvds.c| 2 +- > drivers/gpu/drm/sti/sti_dvo.c | 2 +- > drivers/gpu/drm/sti/sti_hda.c | 1 + > drivers/gpu/drm/sti/sti_hdmi.c | 1 + > include/drm/drm_bridge.h | 8 > 27 files changed, 51 insertions(+), 33 deletions(-) >
Re: [linux-sunxi] [PATCH 3/3] arm64: allwinner: h6: enable MMC0/2 on Pine H64
于 2018年4月27日 GMT+08:00 上午12:46:26, Andre Przywara 写到:
>Hi,
>
>On 26/04/18 15:07, Icenowy Zheng wrote:
>> The Pine H64 board have a MicroSD slot connected to MMC0 controller
>of
>> the H6 SoC and a eMMC slot connected to MMC2.
>>
>> Enable them in the device tree.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 32
>++
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> index d36de5eb81f3..78b1cd54687c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> @@ -20,6 +20,38 @@
>> chosen {
>> stdout-path = "serial0:115200n8";
>> };
>> +
>> +reg_vcc3v3: vcc3v3 {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vcc3v3";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +};
>> +
>> +reg_vcc1v8: vcc1v8 {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vcc1v8";
>> +regulator-min-microvolt = <180>;
>> +regulator-max-microvolt = <180>;
>> +};
>> +};
>> +
>> +&mmc0 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&mmc0_pins>;
>> +vmmc-supply = <®_vcc3v3>;
>
>So this is actually CLDO1 on the AXP, correct?
I remember it's coupled between two LDOs, to provide enough power.
>
>
>> +cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
>> +status = "okay";
>> +};
>> +
>> +&mmc2 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&mmc2_pins>;
>> +vmmc-supply = <®_vcc3v3>;
>> +vqmmc-supply = <®_vcc1v8>;
>
>And this is BLDO2?
Yes.
>
>I am just asking because I want to avoid running into the same problem
>as with the A64 before: that future DTs become incompatible with older
>kernels, because we change the power supply to point to the AXP
>regulators, which this kernel does not support yet.
The answer is just not to keep this compatibility, as it's not
supported option to update DT without updating kernel.
P.S. I think the DT will update twice on the kernel side, the
first time keep reg_vcc3v3 (as it's coupled) but use real
regulator for reg_vcc1v8, the second time use the real
coupled regulator for reg_vcc3v3.
>
>It looks like there are more users of those power rails, so we could
>keep those supplies connected to these fixed regulators here, even with
>AXP-805 support in the kernel.
It's not a good choice.
>
>Or we keep this back until we get proper AXP support in the kernel? I
>guess it's quite close to the existing PMICs, so it might be more a
>copy&paste exercise to support the AXP-805?
It's not a reason to keep it back.
>
>But apart from this this looks correct to me.
>
>Cheers,
>Andre.
>
>> +non-removable;
>> +cap-mmc-hw-reset;
>> +status = "okay";
>> };
>>
>> &uart0 {
>>
Re: [PATCH v3 2/7] kprobes: Show blacklist addresses as same as kallsyms does
* Masami Hiramatsu wrote:
> + /*
> + * As long as kallsyms shows the address, kprobes blacklist also
> + * show it, Or, it shows null address and symbol.
> + */
Please _read_ the comments you write!
In which universe does a capitalized 'Or' make sense, even if we ignore the
various other spelling mistakes?
Also, that sentence is unnecessarily complex, just say this:
> + /*
> + * If /proc/kallsyms is not showing kernel addresses then we won't show
> + * them here either:
> + */
But I'm unhappy about the messy typing and the messy code flow:
+ void *start = (void *)ent->start_addr, *end = (void *)ent->end_addr;
+ /*
+* As long as kallsyms shows the address, kprobes blacklist also
+* show it, Or, it shows null address and symbol.
+*/
+ if (!kallsyms_show_value())
+ start = end = NULL;
+
+ seq_printf(m, "0x%px-0x%px\t%ps\n", start, end,
+ (void *)ent->start_addr);
All three 'void *' type casts here are due to the bad type choices here:
struct kprobe_blacklist_entry {
struct list_head list;
unsigned long start_addr;
unsigned long end_addr;
};
The natural type of ->start_addr and ->end_addr is 'void *', AFAICS this would
remove some other type casts from the kprobes code as well, such as from the
arch_deref_entry_point()...
But the whole code flow introduced by this patch is messy as hell as well.
Why cannot this do the obvious thing:
if (!kallsyms_show_value())
seq_printf(m, "0x%px-0x%px\t%ps\n", NULL, NULL,
ent->start_addr);
else
seq_printf(m, "0x%px-0x%px\t%ps\n", ent->start_addr,
ent->end_addr, ent->start_addr);
?
This variant eliminates the unnecessary complication over local variables and
makes it abundantly clear what gets printed and how.
( Note that the kprobe_blacklist_entry type cleanup should still be done,
regardless of code flow choices. )
Thanks,
Ingo
Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love
On Thu 26-04-18 22:35:56, Christoph Hellwig wrote: > On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote: > > In practice if you don't have a floppy device on x86, you don't need > > ZONE_DMA, > > I call BS on that, and you actually explain later why it it BS due > to some drivers using it more explicitly. But even more importantly > we have plenty driver using it through dma_alloc_* and a small DMA > mask, and they are in use - we actually had a 4.16 regression due to > them. Well, but do we need a zone for that purpose? The idea was to actually replace the zone by a CMA pool (at least on x86). With the current implementation of the CMA we would move the range [0-16M] pfn range into zone_movable so it can be used and we would get rid of all of the overhead each zone brings (a bit in page flags, kmalloc caches and who knows what else) -- Michal Hocko SUSE Labs
recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"
Hello, I've just stumbled across this commit, and I'm wondering if that's actually correct (I too have at least one system where such IDs are reported in MADT): For offline/absent CPUs, the firmware may not know the APIC IDs at the point MADT is built, so I think it is quite reasonable to put ~0 in there. The ACPID spec specifically calls out that the IDs must not change across sleep states, which implies to me that they may change across an offline period of a CPU. IOW I think such entries still need to contribute to the count of disabled CPUs. I notice a similar change has been done for the xAPIC case a while ago by you, Thomas. Jan
Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface
On Thu, Apr 26, 2018 at 07:23:28PM -0700, Sujeev Dias wrote:
> MHI Host Interface is a communication protocol to be used by the host
> to control and communcate with modem over a high speed peripheral bus.
> This module will allow host to communicate with external devices that
> support MHI protocol.
>
> Signed-off-by: Sujeev Dias
No one else has ever reviewed this code before? That's not good, please
at the very least, have someone else at your company go over it first.
I don't want to be the ones having to point out all of the "obvious"
issues :)
> ---
> Documentation/00-INDEX|2 +
> Documentation/devicetree/bindings/bus/mhi.txt | 141 +++
> Documentation/mhi.txt | 235
> drivers/bus/Kconfig | 17 +
> drivers/bus/Makefile |1 +
> drivers/bus/mhi/Makefile |8 +
> drivers/bus/mhi/core/Makefile |1 +
> drivers/bus/mhi/core/mhi_boot.c | 593 ++
> drivers/bus/mhi/core/mhi_dtr.c| 177 +++
> drivers/bus/mhi/core/mhi_init.c | 1290 +
> drivers/bus/mhi/core/mhi_internal.h | 732
> drivers/bus/mhi/core/mhi_main.c | 1476
> +
> drivers/bus/mhi/core/mhi_pm.c | 1177
> include/linux/mhi.h | 694
> include/linux/mod_devicetable.h | 11 +
> 15 files changed, 6555 insertions(+)
And a 6555 line patch is a bit hard to consume all at once. Can't this
be split up into much more reviewable chunks? Look at how some of the
other new bus subsystems got added to the tree recently. They were
submitted in longer patch series, but smaller sized patches
individually. That makes things much easier to review.
For example, there is no reason your debugfs stuff needs to be in this
initial patch. That should be in a separate one, right? Same for
firmware download. Please take the time to break this up into logical
steps.
Like my son's math teacher keeps telling him, "show your work, not just
an answer at the bottom of the page".
Also, it is required by the DT maintainers to split that file alone up
into a separate patch to be even considered for merging.
One thing I can tell you right now that isn't acceptable:
> +#ifdef CONFIG_MHI_DEBUG
Don't have a separate config option for debugging. No one will enable
it, which makes it pointless. Everything has to be dynamic these days.
> +
> +#define MHI_VERB(fmt, ...) do { \
> + if (mhi_cntrl->klog_lvl <= MHI_MSG_LVL_VERBOSE) \
> + pr_debug("[D][%s] " fmt, __func__, ##__VA_ARGS__);\
> +} while (0)
> +
> +#else
> +
> +#define MHI_VERB(fmt, ...)
> +
> +#endif
> +
> +#define MHI_LOG(fmt, ...) do { \
> + if (mhi_cntrl->klog_lvl <= MHI_MSG_LVL_INFO) \
> + pr_info("[I][%s] " fmt, __func__, ##__VA_ARGS__);\
> +} while (0)
> +
> +#define MHI_ERR(fmt, ...) do { \
> + if (mhi_cntrl->klog_lvl <= MHI_MSG_LVL_ERROR) \
> + pr_err("[E][%s] " fmt, __func__, ##__VA_ARGS__); \
> +} while (0)
> +
> +#define MHI_CRITICAL(fmt, ...) do { \
> + if (mhi_cntrl->klog_lvl <= MHI_MSG_LVL_CRITICAL) \
> + pr_alert("[C][%s] " fmt, __func__, ##__VA_ARGS__); \
> +} while (0)
> +
And do not roll your own debugging/logging macros. Use what is given to
you (dev_info(), dev_err(), dev_dbg()), they are there for a reason. By
going around them, you circumvent the whole of the kernel logging
infrastructure and declare that your tiny bus is somehow more "special"
than it.
And I doubt you want to make such a statement :)
thanks,
greg k-h
Re: [PATCH 0/3] can: fix ndo_start_xmit()'s return type
On 04/26/2018 11:13 PM, Luc Van Oostenryck wrote: > ndo_start_xmit() is defined as returing an 'netdev_tx_t'. > However, several can drivers use 'int' as the return type > of their start_xmit() method. > This series contains the fix for all three of them. > > Luc Van Oostenryck (3): > can: janz-ican3: fix ican3_xmit()'s return type > can: sun4i: fix sun4ican_start_xmit()'s return type > can: xilinx: fix xcan_start_xmit()'s return type > > drivers/net/can/janz-ican3.c | 2 +- > drivers/net/can/sun4i_can.c | 2 +- > drivers/net/can/xilinx_can.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) Applied all 3 to linux-can-next, added similar patch for the flexcan driver. Tnx, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] net: phy: marvell: clear wol event before setting it
On Fri, 27 Apr 2018 09:22:34 +0530 Bhadram Varka wrote: > Hi Andrew/Jisheng, > > On 4/26/2018 6:10 PM, Andrew Lunn wrote: > >> hmm, so you want a "stick" WOL feature, I dunno whether Linux kernel > >> requires WOL should be "stick". > > I see two different cases: > > > > Suspend/resume: The WoL state in the kernel is probably kept across > > such a cycle. If so, you would expect another suspend/resume to also > > work, without needs to reconfigure it. > Trying this scenario (suspend/resume) from my side. In this case WoL > should be enabled in the HW. For Marvell PHY to generate WoL interrupt > we need to clear WoL status. > Above mentioned change required to make this happen. Please share your > thoughts on this. I'm fine with that patch. Maybe you could send out a patch? Thanks
Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface
On Thu, Apr 26, 2018 at 07:23:28PM -0700, Sujeev Dias wrote: > --- /dev/null > +++ b/drivers/bus/mhi/core/mhi_boot.c > @@ -0,0 +1,593 @@ > +/* Copyright (c) 2018, The Linux Foundation. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ Also, please use the proper SPDX headers on all new files, and do not put the "boiler-plate" license crud here either. thanks, greg k-h
[PATCH] ARM: dts: imx6sx-sabreauto: add egalax touch screen support
From: Haibo Chen
Add egalax touch screen support on i2c2 bus.
Signed-off-by: Haibo Chen
Signed-off-by: Anson Huang
---
this patch is based on patch (ARM: dts: imx6sx-sabreauto: add debug LED
support) I sent out for review.
arch/arm/boot/dts/imx6sx-sabreauto.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 6b94f24..2f6e474 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -131,6 +131,12 @@
&iomuxc {
imx6x-sabreauto {
+ pinctrl_egalax_int: egalax_intgrp {
+ fsl,pins = <
+ MX6SX_PAD_SD4_RESET_B__GPIO6_IO_22
0x8000
+ >;
+ };
+
pinctrl_led: ledgrp {
fsl,pins = <
MX6SX_PAD_CSI_PIXCLK__GPIO1_IO_24 0x17059
@@ -274,6 +280,16 @@
pinctrl-0 = <&pinctrl_i2c2_1>;
status = "okay";
+ egalax_ts@04 {
+ compatible = "eeti,egalax_ts";
+ reg = <0x04>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_egalax_int>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <22 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-gpios = <&gpio6 22 GPIO_ACTIVE_HIGH>;
+ };
+
max7322: gpio@68 {
compatible = "maxim,max7322";
reg = <0x68>;
--
2.7.4
Re: [PATCH] net: phy: marvell: clear wol event before setting it
On Thu, 26 Apr 2018 12:39:59 +0530 Bhadram Varka wrote:
> >
> > diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> > index c22e8e383247..b6abe1cbc84b 100644
> > --- a/drivers/net/phy/marvell.c
> > +++ b/drivers/net/phy/marvell.c
> > @@ -115,6 +115,9 @@
> > /* WOL Event Interrupt Enable */
> > #define MII_88E1318S_PHY_CSIER_WOL_EIE BIT(7)
> > +/* Copper Specific Interrupt Status Register */
> > +#define MII_88E1318S_PHY_CSISR 0x13
> > +
> > /* LED Timer Control Register */
> > #define MII_88E1318S_PHY_LED_TCR 0x12
> > #define MII_88E1318S_PHY_LED_TCR_FORCE_INT BIT(15)
> > @@ -1393,6 +1396,12 @@ static int m88e1318_set_wol(struct
> > phy_device *phydev,
> > if (err < 0)
> > goto error;
> > + /* If WOL event happened once, the LED[2] interrupt pin
> > + * will not be cleared unless reading the CSISR register.
> > + * So clear the WOL event first before enabling it.
> > + */
> > + phy_read(phydev, MII_88E1318S_PHY_CSISR);
> > +
> Hi Jisheng
>
> The problem with this is, you could be clearing a real interrupt, link
> down/up etc. If interrupts are in use, i think the normal interrupt
> handling will clear the WOL interrupt? So can you make this read
> conditional on !phy_interrupt_is_valid()?
> >>> So this will clear WoL interrupt bit from Copper Interrupt status
> >>> register.
> >>>
> >>> How about clearing WoL status (Page 17, register 17) for every WOL
> >>> event ?
> >>>
> >> This is already properly done by setting
> >> MII_88E1318S_PHY_WOL_CTRL_CLEAR_WOL_STATUS
> >> in m88e1318_set_wol()
> > This part of the code executes only when we enable WOL through ethtool
> > (ethtool -s eth0 wol g)
> >
> > Lets say once WOL enabled through magic packet - HW generates WOL
> > interrupt once magic packet received.
> > The problem that I see here is that for the next immediate magic
> > packet I don't see WOL interrupt generated by the HW.
> > I need to explicitly clear WOL status for HW to generate WOL interrupt.
>
> With the below patch I see WOL event interrupt for every magic packet
> that HW receives...
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index ed8a67d..5d3d138 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -55,6 +55,7 @@
>
> #define MII_M1011_IEVENT 0x13
> #define MII_M1011_IEVENT_CLEAR 0x
> +#define MII_M1011_IEVENT_WOL_EVENT BIT(7)
>
> #define MII_M1011_IMASK 0x12
> - #define MII_M1011_IMASK_INIT 0x6400
> + #define MII_M1011_IMASK_INIT 0x6480
>
> @@ -195,13 +196,40 @@ struct marvell_priv {
> bool copper;
> };
>
> +static int marvell_clear_wol_status(struct phy_device *phydev)
> +{
> + int err, temp, oldpage;
> +
> + oldpage = phy_read(phydev, MII_MARVELL_PHY_PAGE);
> + if (oldpage < 0)
> + return oldpage;
> +
> + err = phy_write(phydev, MII_MARVELL_PHY_PAGE,
> + MII_88E1318S_PHY_WOL_PAGE);
> + if (err < 0)
> + return err;
> +
> + /*
> + * Clear WOL status so that for next WOL event
> + * interrupt will be generated by HW
> + */
> + temp = phy_read(phydev, MII_88E1318S_PHY_WOL_CTRL);
> + temp |= MII_88E1318S_PHY_WOL_CTRL_CLEAR_WOL_STATUS;
> + err = phy_write(phydev, MII_88E1318S_PHY_WOL_CTRL, temp);
is it better to reuse __phy_write()?
> + if (err < 0)
> + return err;
> +
> +
> + phy_write(phydev, MII_MARVELL_PHY_PAGE, oldpage);
> +
> + return 0;
> +}
> +
> static int marvell_ack_interrupt(struct phy_device *phydev)
> {
> int err;
>
> /* Clear the interrupts by reading the reg */
> err = phy_read(phydev, MII_M1011_IEVENT);
> -
> if (err < 0)
> return err;
>
> @@ -1454,12 +1482,18 @@ static int marvell_aneg_done(struct phy_device
> *phydev)
>
> static int m88e1121_did_interrupt(struct phy_device *phydev)
> {
> - int imask;
> + int imask, err;
>
> imask = phy_read(phydev, MII_M1011_IEVENT);
>
> - if (imask & MII_M1011_IMASK_INIT)
> + if (imask & MII_M1011_IMASK_INIT) {
> + if (imask & MII_M1011_IEVENT_WOL_EVENT) {
> + err = marvell_clear_wol_status(phydev);
> + if (err < 0)
> + return 0;
> + }
> return 1;
> + }
>
> return 0;
> }
Re: [PATCH 00/24] device link, bridge supplier <-> drm device
On 2018-04-27 01:18, Laurent Pinchart wrote: > Hi Peter, > > On Friday, 27 April 2018 02:09:14 EEST Peter Rosin wrote: >> On 2018-04-27 00:40, Laurent Pinchart wrote: >>> On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote: Hi! It was noted by Russel King [1] that bridges (not using components) might disappear unexpectedly if the owner of the bridge was unbound. Jyri Sarha had previously noted the same thing with panels [2]. Jyri came up with using device links to resolve the panel issue, which was also my (independent) reaction to the note from Russel. This series builds up to the addition of that link in the last patch, but in my opinion the other 23 patches do have merit on their own. The last patch needs testing, while the others look trivial. That said, I might have missed some subtlety. >>> >>> I don't think this is the way to go. We have a real lifetime management >>> problem with bridges, and device links are just trying to hide the problem >>> under the carpet. They will further corner us by making a real fix much >>> more difficult to implement. I'll try to comment further in the next few >>> days on what I think a better solution would be, but in a nutshell I >>> believe that drm_bridge objects need to be refcounted, with a .release() >>> operation to free the bridge resources when the reference count drops to >>> zero. This shouldn't be difficult to implement and I'm willing to help. >> >> Ok, sp 24/24 is dead, and maybe 23/24 too. > > Not necessarily, maybe I'll get proven wrong :-) Let's discuss, but I first > need some sleep. Ok, I'll add my view... I don't see how a refcount is going to resolve anything. Let's take some device that allocs a bridge that is later attached to some encoder. In doing so it adds hooks to some of the drm_bridge_funcs. If you add a refcount to the bridge itself then yes, the bridge object might remain but the code backing the hook functions will go away the moment the owner device goes away. So, you'd have to refcount the owner device itself to prevent it from going away. But, you can't stop a device from going away IIUC, you can only bring other stuff down with it in an orderly fashion. Components, that some bridges use, takes care of bringing the whole cluster down *before* any device goes away, so that is obviously a solution. But that solution is not in place everywhere. Now, my device-link is pretty light-weight. And it should only matter if the owner goes away before the consuming drm device has brought down the encoder properly. If that ever happens, we're in trouble. So, the link can at worst only substitute one problem with another, and at best it prevents the fireworks. Sure, there's the reprobe problem if the bridge's owner device shows up again, but that's pretty minor compared to a hard crash. And there was a patch for that, so in the end that may be a non-issue. If some other solution is found, removing the device-link is trivial. It is localized to bridge attach/detach and nothing else is affected (in terms of code). Cheers, Peter >> But how do you feel about dropping .of_node in favour of .owner? That gets >> rid of ugly #ifdefs... > > I'll review that part and reply, I have nothing against it on principle at > the > moment. The more generic the code is, the better in my opinion. We just need > to make sure that the OF node we're interested in will always be .owner- >> of_node in all cases. > >> I also have the nagging feeling that .driver_private serves very little real >> purpose if there is a .owner so that you can do >> >> dev_get_drvdata(bridge->owner) >> >> for the cases where the container_of macro is not appropriate. > > I'll review that too, it's a good point. >
Re: stable 4.16.5 hmm build error
On Fri, Apr 27, 2018 at 02:19:24AM +0300, Михаил Носов wrote: > Oh. Yes. Tag v4.16.5 without commit > 9d8a463a7016e9e5578a561588a18acef139919c. > It's in v4.17-rc1/2. > Thank you. That patch does not apply to the stable trees. I'm also confused by the lack of "real" git commit ids that are being referred to here, that commit refers to one that is not valid. > 2018-04-27 0:52 GMT+03:00 Randy Dunlap : > > > https://bugzilla.kernel.org/show_bug.cgi?id=199515 > > > > kernel/fork.o: In function `__mmdrop': > > /kernel/build_kernel/linux-4.16.4/kernel/fork.c:600: undefined reference > > to `hmm_mm_destroy' What .config is creating this? I have not seen any kbuild reports of this in the past. > > > > "It is also reproduced in linux-4.16.5" > > > > > > There have been a few attempts to fix this build error. The kernel > > mainline > > repo seems to have it fixed, but it looks to me like Arnd's latest patch > > (9d8a463a7016e: "mm/hmm: fix header file if/else/endif maze, again") > > was mis-merged to 4.16.5 stable. > > > > Please take a look. Do you already have a fixup for this? thanks, greg k-h
Re: [PATCH v2 2/2] x86/mm: implement free pmd/pte page interfaces
On Thu, Apr 26, 2018 at 10:30:14PM +, Kani, Toshi wrote: > Thanks for the clarification. After reading through SDM one more time, I > agree that we need a TLB purge here. Here is my current understanding. > > - INVLPG purges both TLB and paging-structure caches. So, PMD cache was > purged once. > - However, processor may cache this PMD entry later in speculation > since it has p-bit set. (This is where my misunderstanding was. > Speculation is not allowed to access a target address, but it may still > cache this PMD entry.) > - A single INVLPG on each processor purges this PMD cache. It does not > need a range purge (which was already done). > > Does it sound right to you? The right fix is to first synchronize the changes when the PMD/PUD is cleared and then flush the TLB system-wide. After that is done you can free the page. But doing all that in the pud/pmd_free_pmd/pte_page() functions is too expensive, as the TLB flush requires to send IPIs to all cores in the system, and that every time the function is called. So what needs to be done is to fix this from high-level ioremap code to first unmap all required PTE/PMD pages and collect them in a list. When that is done you can synchronize the changes with the other page-tables in the system and do one system-wide TLB flush. When that is complete you can free the pages on the list that were collected while unmapping. Then the new mappings can be established and again synchronized with the other page-tables in the system. > As for the BUG_ON issue, are you able to reproduce this issue? If so, > would you be able to test the fix? Yes, I can reproduce the BUG_ON with my PTI patches and a fedora-i386 VM. I already ran into the issue before your patches were merged upstream, but my "fix" is different because it just prevents huge-mappings when there were smaller mappings before. See e3e288121408 x86/pgtable: Don't set huge PUD/PMD on non-leaf entries for details. This patch does not fix the base-problem, but hides it again, as the real fix needs some more work across architectures. Your patch actually makes the problem worse, without it the PTE/PMD pages were just leaked, so that they could not be reused. But with your patch the pages can be used again and the page-walker might establish TLB entries based on random content the new owner writes to it. This can lead to all kinds of random and very hard to debug data corruption issues. So until we make the generic ioremap code in lib/ioremap.c smarter about unmapping/remapping ranges the best solution is making my fix work again by reverting your patch. Thanks, Joerg
[PATCH] ptp_pch: use helpers function for converting between ns and timespec
use ns_to_timespec64() and timespec64_to_ns() instead of open coding
Signed-off-by: YueHaibing
---
drivers/ptp/ptp_pch.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index b328517..78ccf93 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -452,7 +452,6 @@ static int ptp_pch_adjtime(struct ptp_clock_info *ptp, s64
delta)
static int ptp_pch_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
u64 ns;
- u32 remainder;
unsigned long flags;
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
struct pch_ts_regs __iomem *regs = pch_dev->regs;
@@ -461,8 +460,7 @@ static int ptp_pch_gettime(struct ptp_clock_info *ptp,
struct timespec64 *ts)
ns = pch_systime_read(regs);
spin_unlock_irqrestore(&pch_dev->register_lock, flags);
- ts->tv_sec = div_u64_rem(ns, 10, &remainder);
- ts->tv_nsec = remainder;
+ *ts = ns_to_timespec64(ns);
return 0;
}
@@ -474,8 +472,7 @@ static int ptp_pch_settime(struct ptp_clock_info *ptp,
struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
struct pch_ts_regs __iomem *regs = pch_dev->regs;
- ns = ts->tv_sec * 10ULL;
- ns += ts->tv_nsec;
+ ns = timespec64_to_ns(ts);
spin_lock_irqsave(&pch_dev->register_lock, flags);
pch_systime_write(regs, ns);
--
2.7.0
Re: [PATCH] sched/numa: Stagger NUMA balancing scan periods for new threads
On Fri, Apr 27, 2018 at 08:50:57AM +0200, Ingo Molnar wrote:
> > 4.17.0-rc1 4.17.0-rc1
> >vanilla stagger-v1r1
> > sys-time-bt.D 48.78 ( 0.00%) 48.22 ( 1.15%)
> > sys-time-cg.D 25.31 ( 0.00%) 26.63 ( -5.22%)
> > sys-time-ep.D 1.65 ( 0.00%)0.62 ( 62.42%)
> > sys-time-is.D 40.05 ( 0.00%) 24.45 ( 38.95%)
> > sys-time-lu.D 37.55 ( 0.00%) 29.02 ( 22.72%)
> > sys-time-mg.D 47.52 ( 0.00%) 34.92 ( 26.52%)
> > sys-time-sp.D119.01 ( 0.00%) 109.05 ( 8.37%)
> > sys-time-ua.D 51.52 ( 0.00%) 45.13 ( 12.40%)
> >
> > NUMA scan activity is reduced as well as other balancing activity.
> >
> > NUMA alloc local 1042828 1342670
> > NUMA base PTE updates14048113893577468
> > NUMA huge PMD updates 272171 180766
> > NUMA page range updates 279832690 186129660
> > NUMA hint faults 1395972 1193897
> > NUMA hint local faults 877925 855053
> > NUMA hint local percent 62 71
> > NUMA pages migrated 12057909 9158023
>
> Looks like a nice reduction in scanning overhead - which was always the main
> worry
> with the fault based active NUMA balancing technique.
>
> I have a couple of minor code cleanliness nit:
>
No problem.
> > +void init_numa_balancing(unsigned long clone_flags, struct task_struct *p)
> > +{
> > + int mm_users = 0;
> > +
> > + if (p->mm) {
> > + mm_users = atomic_read(&p->mm->mm_users);
> > + if (mm_users == 1) {
> > + p->mm->numa_next_scan = jiffies +
> > msecs_to_jiffies(sysctl_numa_balancing_scan_delay);
> > + p->mm->numa_scan_seq = 0;
> > + }
> > + }
> > + p->node_stamp = 0ULL;
> > + p->numa_scan_seq = p->mm ? p->mm->numa_scan_seq : 0;
> > + p->numa_scan_period = sysctl_numa_balancing_scan_delay;
> > + p->numa_work.next = &p->numa_work;
> > + p->numa_faults = NULL;
> > + p->last_task_numa_placement = 0;
> > + p->last_sum_exec_runtime = 0;
> > + p->numa_group = NULL;
>
> While this is pre-existing code that you moved, could we please use a bit
> more
> organization to make this more readable:
>
> p->node_stamp = 0ULL;
> p->numa_scan_seq= p->mm ? p->mm->numa_scan_seq : 0;
> p->numa_scan_period = sysctl_numa_balancing_scan_delay;
> p->numa_work.next = &p->numa_work;
> p->numa_faults = NULL;
> p->last_task_numa_placement = 0;
> p->last_sum_exec_runtime= 0;
> p->numa_group = NULL;
>
> ?
>
> This form made me notice a detail: the 0ULL asymmetry looks weird, this
> integer
> literal type specification is entirely superfluous here, we can just write
> '0'.
>
Can do. I'll revise it and should send a new version on Monday. You're
right that the type is superfluous, this was simply a code movement so I
kept the structure.
> > + /* New address space */
> > + if (!(clone_flags & CLONE_VM)) {
> > + p->numa_preferred_nid = -1;
> > + return;
> > + }
> > +
> > + /* New thread, use existing preferred nid but stagger scans */
> > + if (p->mm) {
> > + unsigned int delay;
> > +
> > + delay = min_t(unsigned int, task_scan_max(current),
> > + current->numa_scan_period * mm_users * NSEC_PER_MSEC);
> > + delay += 2 * TICK_NSEC;
> > + p->numa_preferred_nid = current->numa_preferred_nid;
> > + p->node_stamp = delay;
> > + }
>
> So this is a fork time function, shouldn't p->numa_preferred_nid be equal to
> current->numa_preferred_nid already?
>
It should but I see no harm in being explicit.
> This is what happens in the !p->mm && CLONE_VM case anyway, right?
>
!p->mm should never have changed numa_preferred_nid and it's useless
information anyway. Kernel threads do not have a user address space to
sample and migrate.
> So we could leave out the superfluous assignment and make it clear in a
> comment
> that we inherit the parent's ->numa_preferred_nid intentionally.
>
I can do that.
> Also, there's a lot of p->mm use, could we add this helper local variable to
> simplify the code some more:
>
> struct mm_struct *mm = p->mm;
>
> ?
That should be harmless.
Thanks!
--
Mel Gorman
SUSE Labs
Re: [RFC PATCH RESEND 2/3] leds: upboard: Add LED support
On Thu, 26 Apr 2018, Javier Arteaga wrote:
[...]
> > > static const struct regmap_range upboard_up2_readable_ranges[] = {
> > > @@ -116,7 +124,18 @@ static const struct regmap_config
> > > upboard_up2_regmap_config = {
> > > .wr_table = &upboard_up2_writable_table,
> > > };
> > >
> > > +static struct upboard_led_data upboard_up2_led_data[] = {
> > > + { .id = 0, .color = "blue" },
> > > + { .id = 1, .color = "yellow" },
> > > + { .id = 2, .color = "green" },
> > > + { .id = 3, .color = "red" },
> > > +};
> >
> > How is this data used?
> >
> > Does it ever change, from board to board?
>
> This provides indexes into the LED control register, so the leds driver
> knows which regmap bits to flip, and maps them to color names, so it can
> name the led devices accordingly. The mapping does change for each board
> (UP1 has 3 LEDs, UP Core depends on the carrier board).
I think this information should live in the driver which consumes it.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 00/24] device link, bridge supplier <-> drm device
On 2018-04-27 09:11, Andrzej Hajda wrote: > Hi Peter, > > On 27.04.2018 00:31, Peter Rosin wrote: >> Hi! >> >> It was noted by Russel King [1] that bridges (not using components) >> might disappear unexpectedly if the owner of the bridge was unbound. >> Jyri Sarha had previously noted the same thing with panels [2]. Jyri >> came up with using device links to resolve the panel issue, which >> was also my (independent) reaction to the note from Russel. >> >> This series builds up to the addition of that link in the last >> patch, but in my opinion the other 23 patches do have merit on their >> own. >> >> The last patch needs testing, while the others look trivial. That >> said, I might have missed some subtlety. > > of_node is used as an identifier of the bridge in the kernel. If you > replace it with device pointer there will be potential problem with > devices having two or more bridges, how do you differentiate bridges if > the owner is the same? If I remember correctly current bridge code does > not allow to have multiple bridges in one device, but that should be > quite easy to fix if necessary. After this change it will become more > difficult. I don't see how it will be more difficult? > Anyway I remember discussion that in DT world bridge should be > identified rather by of_graph port node, not by parent node as it is > now. If you want to translate this relation to device owner, you should > add also port number to have full identification of the bridge, ie pair > (owner, port_number) would be equivalent of port node. You even state the trivial solution here, just add the port/endpoint ID when/if it is needed. So, what is the significant difference? Cheers, Peter
Re: [PATCH net-next v2 5/7] MIPS: mscc: Add switch to ocelot
On 26/04/2018 22:51:13+0200, Andrew Lunn wrote:
> > +
> > + mdio0: mdio@107009c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "mscc,ocelot-miim";
> > + reg = <0x107009c 0x36>, <0x10700f0 0x8>;
> > + interrupts = <14>;
> > + status = "disabled";
> > +
> > + phy0: ethernet-phy@0 {
> > + reg = <0>;
> > + };
> > + phy1: ethernet-phy@1 {
> > + reg = <1>;
> > + };
> > + phy2: ethernet-phy@2 {
> > + reg = <2>;
> > + };
> > + phy3: ethernet-phy@3 {
> > + reg = <3>;
> > + };
>
> Hi Alexandre
>
> These are internal PHYs? Is there an option to use external PHYs for
> the ports which have internal PHYs?
>
> I'm just wondering if they should be linked together by default. Or a
> comment added to the commit message about why they are not linked
> together here.
>
They are dual media ports so they are not necessarily using the
integrated PHY but can use SerDEs1G lanes.
I'll add that to the commit message.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Re: possible BUG: selftest about raw_skew failed
On Thu, Apr 26, 2018 at 11:28:29PM +0200, Thomas Gleixner wrote: > On Sat, 21 Apr 2018, Jeffrin Thalakkottoor wrote: > > selftests: raw_skew > > > > WARNING: ADJ_OFFSET in progress, this will cause inaccurate results > > Estimating clock drift: 17.910(est) 16.820(act) [FAILED] Was ntpd, systemd-timesyncd, or some other NTP/PTP daemon running shortly before or during the test? The warning indicates that the clock was slewed by adjtime() or adjtimex(), which makes the measurement of the frequency less accurate and the test may fail. Maybe this test and other tests that measure the frequency of the system clock should be modified to SKIP when adjtimex() returns a non-zero offset (or the frequency changes during the test)? -- Miroslav Lichvar
Re: [PATCH 3/3] can: xilinx: fix xcan_start_xmit()'s return type
On 26.4.2018 23:13, Luc Van Oostenryck wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Fix this by returning 'netdev_tx_t' in this driver too.
>
> Signed-off-by: Luc Van Oostenryck
> ---
> drivers/net/can/xilinx_can.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 89aec07c2..a19648606 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -386,7 +386,7 @@ static int xcan_do_set_mode(struct net_device *ndev, enum
> can_mode mode)
> *
> * Return: 0 on success and failure value on error
> */
> -static int xcan_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> +static netdev_tx_t xcan_start_xmit(struct sk_buff *skb, struct net_device
> *ndev)
> {
> struct xcan_priv *priv = netdev_priv(ndev);
> struct net_device_stats *stats = &ndev->stats;
>
It was applied already but there should be also kernel-doc update too to
use enum values instead of 0.
M
Re: [PATCH 00/24] device link, bridge supplier <-> drm device
On 2018-04-27 09:37, Peter Rosin wrote: > On 2018-04-27 09:11, Andrzej Hajda wrote: >> Hi Peter, >> >> On 27.04.2018 00:31, Peter Rosin wrote: >>> Hi! >>> >>> It was noted by Russel King [1] that bridges (not using components) >>> might disappear unexpectedly if the owner of the bridge was unbound. >>> Jyri Sarha had previously noted the same thing with panels [2]. Jyri >>> came up with using device links to resolve the panel issue, which >>> was also my (independent) reaction to the note from Russel. >>> >>> This series builds up to the addition of that link in the last >>> patch, but in my opinion the other 23 patches do have merit on their >>> own. >>> >>> The last patch needs testing, while the others look trivial. That >>> said, I might have missed some subtlety. >> >> of_node is used as an identifier of the bridge in the kernel. If you >> replace it with device pointer there will be potential problem with >> devices having two or more bridges, how do you differentiate bridges if >> the owner is the same? If I remember correctly current bridge code does >> not allow to have multiple bridges in one device, but that should be >> quite easy to fix if necessary. After this change it will become more >> difficult. > > I don't see how it will be more difficult? > >> Anyway I remember discussion that in DT world bridge should be >> identified rather by of_graph port node, not by parent node as it is >> now. If you want to translate this relation to device owner, you should >> add also port number to have full identification of the bridge, ie pair >> (owner, port_number) would be equivalent of port node. > > You even state the trivial solution here, just add the port/endpoint ID > when/if it is needed. So, what is the significant difference? Or, since this is apparently a rare requirement, you could make the owners that do need it fix it themselves. E.g. by embedding the struct drm_bridge in another struct that contains the needed ID, and use container_of to get to that containing struct with the ID. Cheers, Peter
Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers
On Fri, Apr 27, 2018 at 4:28 AM, David Lechner wrote: > On 04/26/2018 12:31 PM, Rich Felker wrote: >> >> On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote: >>> >>> From: Bartosz Golaszewski >>> >>> This is a follow to my series[1] the aim of which was to introduce device >>> tree >>> support for early platform devices. >>> >>> It was received rather negatively. Aside from using device tree to pass >>> implementation specific details to the system, two important concerns >>> were >>> raised: no probe deferral support and the fact that currently the early >>> devices >>> never get converted to actual platform drivers. This series is a >>> proof-of-concept that's trying to address those issues. >>> >>> The only user of the current version of early platform drivers is the >>> SuperH >>> architecture. If this series eventually gets merged, we could simply >>> replace >>> the other solution. >> >> >> Looking at a quick output of: >> >> grep -r -A10 early_devices[[] arch/sh/kernel/ >> >> it looks like all of the existing early platform devices are serial >> ports, clocks, and clocksources. The switch to device tree should pick >> them all up from CLK_OF_DECLARE, TIMER_OF_DECLARE, and >> EARLYCON_DECLARE. Until that's complete, the existing code works >> as-is. I don't see what problem you're trying to solve. > > > The problem for us is that clk maintainers don't want new drivers to use > CLK_OF_DECLARE and instead use platform devices. I have just written such > a new driver that is shared by 6 different SoCs. For some combinations of > SoCs and clocks, using a platform device is fine but on others we need to > register early, so the drivers now have to handle both cases, which is > kind of messy and fragile. If there is a generic way to register platform > devices early, then the code is simplified because we only have to handle > one method of registering the clocks instead of two. The early_platform code is certainly not a way to make things simpler, it just adds one more way of doing the same thing that OF_CLK_DECLARE already does. We removed the last early_platform users on ARM a few years ago, and I would hope to leave it like that. I haven't seen the discussion about your clock drivers, but I know that usually only a very small subset of the clocks on an SoC are needed that 'early', and you should use a regular platform driver for the rest. Can you elaborate on which devices need to access your clocks before you are able to initialize the clk driver through the regular platform_driver framework? Do any of these need complex interactions with the clk subsystem, or do you just need to ensure they are turned on? Arnd
Re: [PATCH] perf test: Adapt test case record+probe_libc_inet_pton.sh for s390
On 04/26/2018 05:26 PM, Martin Vuille wrote: > > > On 04/26/18 04:09, Thomas-Mich Richter wrote: >> was different. With you patch it changed from /usr/lib64/libc.so (old) to >> /usr/lib/debug/lib64/libc-2.26.so.debug (new) >> > Thomas, > > Can you tell me what 'file' reports for the old and new files? > > Regards, > MV > Martin, not sure I understand your question: Before your patch the file which was picked by dwarf was /usr/lib64/libc.so With your patch file which was picked by dwarf was /usr/lib/debug/lib64/libc-2.26.so.debug Was this your question? -- Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany -- Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: [PATCH 3/3] can: xilinx: fix xcan_start_xmit()'s return type
On 04/27/2018 09:49 AM, Michal Simek wrote:
> On 26.4.2018 23:13, Luc Van Oostenryck wrote:
>> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
>> which is a typedef for an enum type, but the implementation in this
>> driver returns an 'int'.
>>
>> Fix this by returning 'netdev_tx_t' in this driver too.
>>
>> Signed-off-by: Luc Van Oostenryck
>> ---
>> drivers/net/can/xilinx_can.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
>> index 89aec07c2..a19648606 100644
>> --- a/drivers/net/can/xilinx_can.c
>> +++ b/drivers/net/can/xilinx_can.c
>> @@ -386,7 +386,7 @@ static int xcan_do_set_mode(struct net_device *ndev,
>> enum can_mode mode)
>> *
>> * Return: 0 on success and failure value on error
>> */
>> -static int xcan_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> +static netdev_tx_t xcan_start_xmit(struct sk_buff *skb, struct net_device
>> *ndev)
>> {
>> struct xcan_priv *priv = netdev_priv(ndev);
>> struct net_device_stats *stats = &ndev->stats;
>>
>
> It was applied already but there should be also kernel-doc update too to
> use enum values instead of 0.
Like this:
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index f07ce4945356..d0ad1473f689 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -398,7 +398,7 @@ static int xcan_do_set_mode(struct net_device *ndev, enum
> can_mode mode)
> * function uses the next available free txbuff and populates their fields to
> * start the transmission.
> *
> - * Return: 0 on success and failure value on error
> + * Return: NETDEV_TX_OK on success and NETDEV_TX_BUSY when the tx queue is
> full
> */
> static netdev_tx_t xcan_start_xmit(struct sk_buff *skb, struct net_device
> *ndev)
> {
I can squash in that change.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
[GIT PULL] mtd: Fixes for 4.17-rc3
Hello Linus,
Here is the MTD fixes PR for 4.17-rc3.
Regards,
Boris
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.infradead.org/linux-mtd.git tags/mtd/fixes-for-4.17-rc3
for you to fetch changes up to f6997bec6af43396ff530caee79e178d32774a49:
mtd: rawnand: marvell: fix the chip-select DT parsing logic (2018-04-26
19:06:42 +0200)
* Fix nanddev_mtd_erase() function to match the changes done in
e7bfb3fdbde3 ("mtd: Stop updating erase_info->state and calling
mtd_erase_callback()")
* Fix a memory leak in the Tango NAND controller driver
* Fix read/write to a suspended erase block in the CFI driver
* Fix the DT parsing logic in the Marvell NAND controller driver
Boris Brezillon (1):
mtd: nand: Fix nanddev_mtd_erase()
Joakim Tjernlund (3):
mtd: cfi: cmdset_0001: Do not allow read/write to suspend erase block.
mtd: cfi: cmdset_0001: Workaround Micron Erase suspend bug.
mtd: cfi: cmdset_0002: Do not allow read/write to suspend erase block.
Marc Gonzalez (1):
mtd: rawnand: tango: Fix struct clk memory leak
Miquel Raynal (1):
mtd: rawnand: marvell: fix the chip-select DT parsing logic
Thor Thayer (1):
mtd: spi-nor: cadence-quadspi: Fix page fault kernel panic
drivers/mtd/chips/cfi_cmdset_0001.c | 33 -
drivers/mtd/chips/cfi_cmdset_0002.c | 9 ++---
drivers/mtd/nand/core.c | 3 ---
drivers/mtd/nand/raw/marvell_nand.c | 25 -
drivers/mtd/nand/raw/tango_nand.c | 2 +-
drivers/mtd/spi-nor/cadence-quadspi.c | 19 +--
include/linux/mtd/flashchip.h | 1 +
7 files changed, 61 insertions(+), 31 deletions(-)
Re: [PATCH] firmware: dmi: Add access to the SKU ID string
Hi Simon, On Tue, 24 Apr 2018 15:11:11 -0600, Simon Glass wrote: > This is used in some systems from user space for determining the identity > of the device. > > Expose this as a file so that that user-space tools don't need to read > from /sys/firmware/dmi/tables/DMI > > Signed-off-by: Simon Glass > --- > > drivers/firmware/dmi-id.c | 2 ++ > drivers/firmware/dmi_scan.c | 1 + > include/linux/mod_devicetable.h | 1 + > 3 files changed, 4 insertions(+) > (...) Looks good to me. Applied, thanks. For consistency I have moved product SKU before product family in all files, same order as in the DMI entry itself. -- Jean Delvare SUSE L3 Support
Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)
Geert Uytterhoeven - 26.04.18, 13:08: > On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald > > wrote: > > You probably put your stick into a cave with ancient sleeping > > dragons > > > > Added in linux-m68k mailing list, as they likely have an opinion on > > how to treat affs + RDB partition support. Also added in Jens Axboe > > about patching that RDB support broken with 2 TB or larger > > harddisks issue which had been in Linux kernel for 6 years while a > > patch exists that to my testing back then solves the issue. […] > If there are bugs in the RDB parser that people run into, they should > be fixed. > If there are limitations in the RDB format on large disks, that's > still not a reason to move it to staging (hi msdos partitioning!). What I ran into was *not* a limitation in the RDB format, but a bug in the Linux implementation on it. After Joanne Dow´s change the 2 TB disk was detected and handled properly by Linux. Also AmigaOS 4.x handles those disks just well and I think also AmigaOS 3.1/3.5/3.9 supported them, but I am not sure on the details on that, it has been a long time since I last booted one of my Amiga systems. Many classic Amiga users may not deal with such large disks, but AmigaOS 4 users probably still, and some of them may run Linux on their PowerPC motherboards as well. So I think the issue is worth fixing and am looking into submitting the fix, which looks pretty straight-forward to me upstream unless someone bets me to it. Thanks, -- Martin
Re: [PATCH 3/3] can: xilinx: fix xcan_start_xmit()'s return type
On 27.4.2018 09:55, Marc Kleine-Budde wrote:
> On 04/27/2018 09:49 AM, Michal Simek wrote:
>> On 26.4.2018 23:13, Luc Van Oostenryck wrote:
>>> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
>>> which is a typedef for an enum type, but the implementation in this
>>> driver returns an 'int'.
>>>
>>> Fix this by returning 'netdev_tx_t' in this driver too.
>>>
>>> Signed-off-by: Luc Van Oostenryck
>>> ---
>>> drivers/net/can/xilinx_can.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
>>> index 89aec07c2..a19648606 100644
>>> --- a/drivers/net/can/xilinx_can.c
>>> +++ b/drivers/net/can/xilinx_can.c
>>> @@ -386,7 +386,7 @@ static int xcan_do_set_mode(struct net_device *ndev,
>>> enum can_mode mode)
>>> *
>>> * Return: 0 on success and failure value on error
>>> */
>>> -static int xcan_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>>> +static netdev_tx_t xcan_start_xmit(struct sk_buff *skb, struct net_device
>>> *ndev)
>>> {
>>> struct xcan_priv *priv = netdev_priv(ndev);
>>> struct net_device_stats *stats = &ndev->stats;
>>>
>>
>> It was applied already but there should be also kernel-doc update too to
>> use enum values instead of 0.
>
> Like this:
>
>> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
>> index f07ce4945356..d0ad1473f689 100644
>> --- a/drivers/net/can/xilinx_can.c
>> +++ b/drivers/net/can/xilinx_can.c
>> @@ -398,7 +398,7 @@ static int xcan_do_set_mode(struct net_device *ndev,
>> enum can_mode mode)
>> * function uses the next available free txbuff and populates their fields
>> to
>> * start the transmission.
>> *
>> - * Return: 0 on success and failure value on error
>> + * Return: NETDEV_TX_OK on success and NETDEV_TX_BUSY when the tx queue is
>> full
>> */
>> static netdev_tx_t xcan_start_xmit(struct sk_buff *skb, struct net_device
>> *ndev)
>> {
>
> I can squash in that change.
looks good to me.
Acked-by: Michal Simek
Thanks,
Michal
[PATCH] inode: debugfs_create_dir uses mode permission from parent
Currently function debugfs_create_dir() creates a new
directory in the debugfs (usually mounted /sys/kernel/debug)
with permission rwxr-xr-x. This is hard coded.
Change this to use the parent directory permission.
Fixes: edac65eaf8d5c ("debugfs: take mode-dependent parts of
debugfs_get_inode() into callers")
Signed-off-by: Thomas Richter
Cc: Greg Kroah-Hartman
---
fs/debugfs/inode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 13b01351dd1c..80618330d86a 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -512,7 +512,10 @@ struct dentry *debugfs_create_dir(const char *name, struct
dentry *parent)
if (unlikely(!inode))
return failed_creating(dentry);
- inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
+ if(!parent)
+ parent = debugfs_mount->mnt_root;
+ inode->i_mode = S_IFDIR | (d_inode(parent)->i_mode
+ & (S_IRWXU | S_IRWXG));
inode->i_op = &simple_dir_inode_operations;
inode->i_fop = &simple_dir_operations;
--
2.14.3
Re: [PATCH v4 1/5] efi: Export boot-services code and data as debugfs-blobs
Hi, On 26-04-18 23:35, Ard Biesheuvel wrote: On 26 April 2018 at 23:02, Hans de Goede wrote: Hi, On 26-04-18 18:51, Ard Biesheuvel wrote: On 26 April 2018 at 14:06, Hans de Goede wrote: Sometimes it is useful to be able to dump the efi boot-services code and data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, but only if efi=debug is passed on the kernel-commandline as this requires not freeing those memory-regions, which costs 20+ MB of RAM. Reviewed-by: Greg Kroah-Hartman Signed-off-by: Hans de Goede --- Changes in v4: -Add new EFI_BOOT_SERVICES flag and use it to determine if the boot-services memory segments are available (and thus if it makes sense to register the debugfs bits for them) Changes in v2: -Do not call pr_err on debugfs call failures --- arch/x86/platform/efi/efi.c| 1 + arch/x86/platform/efi/quirks.c | 4 +++ drivers/firmware/efi/efi.c | 53 ++ include/linux/efi.h| 1 + 4 files changed, 59 insertions(+) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 9061babfbc83..568b7ee3d323 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -208,6 +208,7 @@ int __init efi_memblock_x86_reserve_range(void) efi.memmap.desc_version); memblock_reserve(pmap, efi.memmap.nr_map * efi.memmap.desc_size); + set_bit(EFI_BOOT_SERVICES, &efi.flags); I think it would be better if the flag conveys whether boot services regions are being preserved, because they will always exist when EFI_BOOT is set. The name should then reflect that as well, e.g., EFI_PRESERVE_BS_REGIONS. Ok, I will rename the flag to EFI_PRESERVE_BS_REGIONS for v5 (I'm going to wait a bit with sending out v5 to give others a change to comment on v4). return 0; } diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c index 36c1f8b9f7e0..16bdb9e3b343 100644 --- a/arch/x86/platform/efi/quirks.c +++ b/arch/x86/platform/efi/quirks.c @@ -376,6 +376,10 @@ void __init efi_free_boot_services(void) int num_entries = 0; void *new, *new_md; + /* Keep all regions for /sys/kernel/debug/efi */ + if (efi_enabled(EFI_DBG)) + return; + Why is this only necessary when EFI_DBG is enabled? How are you ensuring that the firmware is still in memory when the subsequent patches start relying on that? The 2nd patch in this series makes init/main.c call efi_check_for_embedded_firmwares() before efi_free_boot_services(), efi_check_for_embedded_firmwares() then walks the dmi_system_id-s "registered" (its a static list) by drivers and if their is a dmi_match searches for the firmware described by the dmi_system_id.driver_data ptr. If a firmware gets found it gets memdup-ed, so that we do not have to keep all of the boot-services code around. Right, thanks for clearing that up. So that means that preserving the boot regions is really only necessary if you want to inspect them via debugfs, and the firmware loader does not rely on that. I missed that part. That means the only reason we have the new flag is to ensure that the shared debugfs code only exposes the boot services regions if they were preserved to begin with by the arch code, right? Mostly right, since we have the flag now anyways I'm also using it as a condition to call efi_check_for_embedded_firmwares(), efi_check_for_embedded_firmwares() needs to happen after mm_init() (*) and on non x86 the boot-services code/data is long gone then so there is nothing for efi_check_for_embedded_firmwares() to look at. If so, after the flag rename: Acked-by: Ard Biesheuvel I assume that the "mostly right" is good enough and I'm going to add your Acked-by for the next version. Let me know if you've any objections against that. Regards, Hans *) efi_check_for_embedded_firmwares() mremap()s the boot-services memory segments to scan then and they are too big for early_mremap()
[PATCH v2 1/6] dt-bindings: gpu: mali-utgard: add mediatek,mt7623-mali compatible
From: Sean Wang
The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it
and define its own vendor-specific properties.
Reviewed-by: Rob Herring
Signed-off-by: Sean Wang
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index 99d1c0a..656068f 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -19,6 +19,7 @@ Required properties:
+ rockchip,rk3228-mali
+ rockchip,rk3328-mali
+ stericsson,db8500-mali
+ + mediatek,mt7623-mali
- reg: Physical base address and length of the GPU registers
@@ -89,6 +90,14 @@ to specify one more vendor-specific compatible, among:
* interrupt-names and interrupts:
+ combined: combined interrupt of all of the above lines
+ - mediatek,mt7623-mali
+ Required properties:
+ * resets: phandle to the reset line for the GPU
+ * mediatek,larb: phandle pointed to the local arbiter used to control the
+ access to external memory on the SoC.
+ see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+ for details
+
Example:
mali: gpu@1c4 {
--
2.7.4
[PATCH v2 2/6] dt-bindings: clock: mediatek: add g3dsys bindings
From: Sean Wang
Add bindings to g3dsys providing necessary clock and reset control to
Mali-450.
Signed-off-by: Sean Wang
---
.../bindings/arm/mediatek/mediatek,g3dsys.txt | 30 ++
1 file changed, 30 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
new file mode 100644
index 000..7de43bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
@@ -0,0 +1,30 @@
+MediaTek g3dsys controller
+
+
+The MediaTek g3dsys controller provides various clocks and reset controller to
+the GPU.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt2701-g3dsys", "syscon":
+ for MT2701 SoC
+ - "mediatek,mt7623-g3dsys", "mediatek,mt2701-g3dsys", "syscon":
+ for MT7623 SoC
+- #clock-cells: Must be 1
+- #reset-cells: Must be 1
+
+The g3dsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+g3dsys: clock-controller@1300 {
+ compatible = "mediatek,mt7623-g3dsys",
+"mediatek,mt2701-g3dsys",
+"syscon";
+ reg = <0 0x1300 0 0x200>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
--
2.7.4
[PATCH v2 4/6] dt-bindings: reset: mediatek: add entry for Mali-450 node to refer
From: Sean Wang Just add binding for a required reset referenced by Mali-450 on MT7623 or MT2701 SoC. Cc: devicet...@vger.kernel.org Signed-off-by: Sean Wang --- include/dt-bindings/reset/mt2701-resets.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dt-bindings/reset/mt2701-resets.h b/include/dt-bindings/reset/mt2701-resets.h index 21deb54..50b7f06 100644 --- a/include/dt-bindings/reset/mt2701-resets.h +++ b/include/dt-bindings/reset/mt2701-resets.h @@ -87,4 +87,7 @@ #define MT2701_ETHSYS_GMAC_RST 23 #define MT2701_ETHSYS_PPE_RST 31 +/* G3DSYS resets */ +#define MT2701_G3DSYS_CORE_RST 0 + #endif /* _DT_BINDINGS_RESET_CONTROLLER_MT2701 */ -- 2.7.4
[PATCH v2 3/6] dt-bindings: clock: mediatek: add entry for Mali-450 node to refer
From: Sean Wang Just add binding for a required clock referenced by Mali-450 on MT7623 or MT2701 SoC. Cc: devicet...@vger.kernel.org Signed-off-by: Sean Wang --- include/dt-bindings/clock/mt2701-clk.h | 4 1 file changed, 4 insertions(+) diff --git a/include/dt-bindings/clock/mt2701-clk.h b/include/dt-bindings/clock/mt2701-clk.h index 24e93df..2ac62a6 100644 --- a/include/dt-bindings/clock/mt2701-clk.h +++ b/include/dt-bindings/clock/mt2701-clk.h @@ -431,6 +431,10 @@ #define CLK_ETHSYS_CRYPTO 8 #define CLK_ETHSYS_NR 9 +/* G3DSYS */ +#define CLK_G3DSYS_CORE1 +#define CLK_G3DSYS_NR 2 + /* BDP */ #define CLK_BDP_BRG_BA 1 -- 2.7.4
[PATCH v2 5/6] clk: mediatek: add g3dsys support for MT2701 and MT7623
From: Sean Wang
Add clock driver support for g3dsys on MT2701 and MT7623, which is
providing essential clock gate and reset controller to Mali-450.
Signed-off-by: Sean Wang
---
drivers/clk/mediatek/Kconfig | 6 +++
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt2701-g3d.c | 95 +++
3 files changed, 102 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt2701-g3d.c
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 92afe59..3dd1dab 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -60,6 +60,12 @@ config COMMON_CLK_MT2701_AUDSYS
---help---
This driver supports Mediatek MT2701 audsys clocks.
+config COMMON_CLK_MT2701_G3DSYS
+ bool "Clock driver for MediaTek MT2701 g3dsys"
+ depends on COMMON_CLK_MT2701
+ ---help---
+ This driver supports MediaTek MT2701 g3dsys clocks.
+
config COMMON_CLK_MT2712
bool "Clock driver for MediaTek MT2712"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index b80eff2..844b55d 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
obj-$(CONFIG_COMMON_CLK_MT2701_AUDSYS) += clk-mt2701-aud.o
obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
+obj-$(CONFIG_COMMON_CLK_MT2701_G3DSYS) += clk-mt2701-g3d.o
obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
obj-$(CONFIG_COMMON_CLK_MT2701_IMGSYS) += clk-mt2701-img.o
obj-$(CONFIG_COMMON_CLK_MT2701_MMSYS) += clk-mt2701-mm.o
diff --git a/drivers/clk/mediatek/clk-mt2701-g3d.c
b/drivers/clk/mediatek/clk-mt2701-g3d.c
new file mode 100644
index 000..1328c11
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701-g3d.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Sean Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+#include
+
+#define GATE_G3D(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = &g3d_cg_regs, \
+ .shift = _shift,\
+ .ops = &mtk_clk_gate_ops_setclr,\
+ }
+
+static const struct mtk_gate_regs g3d_cg_regs = {
+ .sta_ofs = 0x0,
+ .set_ofs = 0x4,
+ .clr_ofs = 0x8,
+};
+
+static const struct mtk_gate g3d_clks[] = {
+ GATE_G3D(CLK_G3DSYS_CORE, "g3d_core", "mfg_sel", 0),
+};
+
+static int clk_mt2701_g3dsys_init(struct platform_device *pdev)
+{
+ struct clk_onecell_data *clk_data;
+ struct device_node *node = pdev->dev.of_node;
+ int r;
+
+ clk_data = mtk_alloc_clk_data(CLK_G3DSYS_NR);
+
+ mtk_clk_register_gates(node, g3d_clks, ARRAY_SIZE(g3d_clks),
+ clk_data);
+
+ r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+ if (r)
+ dev_err(&pdev->dev,
+ "could not register clock provider: %s: %d\n",
+ pdev->name, r);
+
+ mtk_register_reset_controller(node, 1, 0xc);
+
+ return r;
+}
+
+static const struct of_device_id of_match_clk_mt2701_g3d[] = {
+ {
+ .compatible = "mediatek,mt2701-g3dsys",
+ .data = clk_mt2701_g3dsys_init,
+ }, {
+ /* sentinel */
+ }
+};
+
+static int clk_mt2701_g3d_probe(struct platform_device *pdev)
+{
+ int (*clk_init)(struct platform_device *);
+ int r;
+
+ clk_init = of_device_get_match_data(&pdev->dev);
+ if (!clk_init)
+ return -EINVAL;
+
+ r = clk_init(pdev);
+ if (r)
+ dev_err(&pdev->dev,
+ "could not register clock provider: %s: %d\n",
+ pdev->name, r);
+
+ return r;
+}
+
+static struct platform_driver clk_mt2701_g3d_drv = {
+ .probe = clk_mt2701_g3d_probe,
+ .driver = {
+ .name = "clk-mt2701-g3d",
+ .of_match_table = of_match_clk_mt2701_g3d,
+ },
+};
+
+builtin_platform_driver(clk_mt2701_g3d_drv);
--
2.7.4
[PATCH v2 6/6] arm: dts: mt7623: add Mali-450 and related device nodes
From: Sean Wang
Add nodes for Mali-450 device, g3dsys device providing required clock
gate and reset control and larb3 offering an arbiter through iommu for
controlling access to external memory requested from Mali-450.
Signed-off-by: Sean Wang
---
arch/arm/boot/dts/mt7623.dtsi | 70 ++
arch/arm/boot/dts/mt7623a.dtsi | 4 +++
2 files changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 59139dd..1cd8208 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -276,6 +276,17 @@
clock-names = "system-clk", "rtc-clk";
};
+ smi_common: smi@1000c000 {
+ compatible = "mediatek,mt7623-smi-common",
+"mediatek,mt2701-smi-common";
+ reg = <0 0x1000c000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_SMI>,
+<&mmsys CLK_MM_SMI_COMMON>,
+<&infracfg CLK_INFRA_SMI>;
+ clock-names = "apb", "smi", "async";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
pwrap: pwrap@1000d000 {
compatible = "mediatek,mt7623-pwrap",
"mediatek,mt2701-pwrap";
@@ -307,6 +318,17 @@
reg = <0 0x10200100 0 0x1c>;
};
+ iommu: iommu@10205000 {
+ compatible = "mediatek,mt7623-m4u",
+"mediatek,mt2701-m4u";
+ reg = <0 0x10205000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_M4U>;
+ clock-names = "bclk";
+ mediatek,larbs = <&larb3>;
+ #iommu-cells = <1>;
+ };
+
efuse: efuse@10206000 {
compatible = "mediatek,mt7623-efuse",
"mediatek,mt8173-efuse";
@@ -682,6 +704,54 @@
status = "disabled";
};
+ g3dsys: clock-controller@1300 {
+ compatible = "mediatek,mt7623-g3dsys",
+"mediatek,mt2701-g3dsys",
+"syscon";
+ reg = <0 0x1300 0 0x200>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ larb3: larb@1301 {
+ compatible = "mediatek,mt7623-smi-larb",
+"mediatek,mt2701-smi-larb";
+ reg = <0 0x1301 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larb-id = <3>;
+ clocks = <&clk26m>, <&clk26m>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_MFG>;
+ };
+
+ mali: gpu@1304 {
+ compatible = "mediatek,mt7623-mali", "arm,mali-450";
+ reg = <0 0x1304 0 0x3>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+;
+ interrupt-names = "gp", "gpmmu", "pp0", "ppmmu0", "pp1",
+ "ppmmu1", "pp2", "ppmmu2", "pp";
+ clocks = <&topckgen CLK_TOP_MMPLL>,
+<&g3dsys CLK_G3DSYS_CORE>;
+ clock-names = "bus", "core";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_MFG>;
+ mediatek,larb = <&larb3>;
+ resets = <&g3dsys MT2701_G3DSYS_CORE_RST>;
+ };
+
+ mmsys: syscon@1400 {
+ compatible = "mediatek,mt2701-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
hifsys: syscon@1a00 {
compatible = "mediatek,mt7623-hifsys",
"mediatek,mt2701-hifsys",
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index 0735a1fb8..a42fd46 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -21,6 +21,10 @@
power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
};
+&mali {
+ status = "disabled";
+};
+
&nandc {
power-domains = <&scpsys MT7623A_POWER_DOMAIN_IFR_MSC>;
};
--
2.7.4
[PATCH v2 0/6] add Mali-450 support to MT7623 SoC
From: Sean Wang v2: changes from v1 to v2: - Add Reviewed-by tag from v1 result - Split out the changes for dt-bindings .h from the changes for driver - Fix up the typo in g3dsys dt-bindings documentation v1: Hi, The series adds a required resource setup to allow Mali-450 to work on MT7623. This also can benefits other MediaTek SoCs having Mali-450 device. In order to prove the setup is proper, I also have added mediatek port to linux-lima at [1] and make a few of tests along with off-screen rendering [2][3][4][5][6][7] through mesa-lima [8]. All work correctly. [1] https://github.com/objelf/linux-lima/tree/mediatek-lima-4.16-rc5 [2] simple triangle: https://github.com/yuq/gfx/tree/master/gbm-surface [3] vertex shader uniform: https://github.com/yuq/gfx/tree/master/gbm-surface-move [4] multi varying: https://github.com/yuq/gfx/tree/master/gbm-surface-color [5] multi draw: https://github.com/yuq/gfx/tree/master/gbm-surface-draw [6] FBO: https://github.com/yuq/gfx/tree/master/gbm-surface-fbo [7] kmscube: https://github.com/yuq/kmscube [8] https://github.com/yuq/mesa-lima Hope these patches can help people working on BPI-R2. Sean Sean Wang (6): dt-bindings: gpu: mali-utgard: add mediatek,mt7623-mali compatible dt-bindings: clock: mediatek: add g3dsys bindings dt-bindings: clock: mediatek: add entry for Mali-450 node to refer dt-bindings: reset: mediatek: add entry for Mali-450 node to refer clk: mediatek: add g3dsys support for MT2701 and MT7623 arm: dts: mt7623: add Mali-450 and related device nodes .../bindings/arm/mediatek/mediatek,g3dsys.txt | 30 +++ .../devicetree/bindings/gpu/arm,mali-utgard.txt| 9 ++ arch/arm/boot/dts/mt7623.dtsi | 70 arch/arm/boot/dts/mt7623a.dtsi | 4 + drivers/clk/mediatek/Kconfig | 6 ++ drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt2701-g3d.c | 95 ++ include/dt-bindings/clock/mt2701-clk.h | 4 + include/dt-bindings/reset/mt2701-resets.h | 3 + 9 files changed, 222 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt create mode 100644 drivers/clk/mediatek/clk-mt2701-g3d.c -- 2.7.4
Re: stable 4.16.5 hmm build error
On Fri, Apr 27, 2018 at 9:30 AM, Greg Kroah-Hartman
wrote:
> On Fri, Apr 27, 2018 at 02:19:24AM +0300, Михаил Носов wrote:
>> Oh. Yes. Tag v4.16.5 without commit
>> 9d8a463a7016e9e5578a561588a18acef139919c.
>> It's in v4.17-rc1/2.
>> Thank you.
>
> That patch does not apply to the stable trees. I'm also confused by the
> lack of "real" git commit ids that are being referred to here, that
> commit refers to one that is not valid.
>
>> 2018-04-27 0:52 GMT+03:00 Randy Dunlap :
>>
>> > https://bugzilla.kernel.org/show_bug.cgi?id=199515
>> >
>> > kernel/fork.o: In function `__mmdrop':
>> > /kernel/build_kernel/linux-4.16.4/kernel/fork.c:600: undefined reference
>> > to `hmm_mm_destroy'
>
> What .config is creating this? I have not seen any kbuild reports of
> this in the past.
I only got this through randconfig builds on mainline.
>> >
>> > "It is also reproduced in linux-4.16.5"
>> >
>> >
>> > There have been a few attempts to fix this build error. The kernel
>> > mainline
>> > repo seems to have it fixed, but it looks to me like Arnd's latest patch
>> > (9d8a463a7016e: "mm/hmm: fix header file if/else/endif maze, again")
>> > was mis-merged to 4.16.5 stable.
>> >
>> > Please take a look. Do you already have a fixup for this?
Jérôme initially created
6b368cd4a44c ("mm/hmm: avoid bloating arch that do not make use of HMM")
which is part of v4.16. He noticed a build error that he fixed up with commit
b28b08de436a ("mm/hmm: fix header file if/else/endif maze")
which you backported as 25df8b83e867 into linux-4.16.y after v4.16.4.
After that originally landed in mainline, I found another build error that
I fixed with commit
9d8a463a7016 ("mm/hmm: fix header file if/else/endif maze, again")
This fixes the issue that Randy is reporting now, please add that into
v4.16.5.
Arnd
[PATCH] drivers: net: replace UINT64_MAX with U64_MAX
U64_MAX is well defined now while the UINT64_MAX is not, so we fall
back to drivers' own definition as below:
#ifndef UINT64_MAX
#define UINT64_MAX (u64)(~((u64)0))
#endif
I believe this is in one phy driver then copied and pasted to other phy
drivers.
Replace the UINT64_MAX with U64_MAX to clean up the source code.
Signed-off-by: Jisheng Zhang
---
drivers/net/dsa/mv88e6xxx/chip.c | 6 +++---
drivers/net/dsa/mv88e6xxx/chip.h | 4
drivers/net/phy/bcm-phy-lib.c| 6 +-
drivers/net/phy/marvell.c| 5 +
drivers/net/phy/micrel.c | 5 +
drivers/net/phy/smsc.c | 5 +
6 files changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 3d2091099f7f..1a2dd340853f 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -665,13 +665,13 @@ static uint64_t _mv88e6xxx_get_ethtool_stat(struct
mv88e6xxx_chip *chip,
case STATS_TYPE_PORT:
err = mv88e6xxx_port_read(chip, port, s->reg, ®);
if (err)
- return UINT64_MAX;
+ return U64_MAX;
low = reg;
if (s->size == 4) {
err = mv88e6xxx_port_read(chip, port, s->reg + 1, ®);
if (err)
- return UINT64_MAX;
+ return U64_MAX;
high = reg;
}
break;
@@ -685,7 +685,7 @@ static uint64_t _mv88e6xxx_get_ethtool_stat(struct
mv88e6xxx_chip *chip,
mv88e6xxx_g1_stats_read(chip, reg + 1, &high);
break;
default:
- return UINT64_MAX;
+ return U64_MAX;
}
value = (((u64)high) << 16) | low;
return value;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index 80490f66bc06..4163c8099d0b 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -21,10 +21,6 @@
#include
#include
-#ifndef UINT64_MAX
-#define UINT64_MAX (u64)(~((u64)0))
-#endif
-
#define SMI_CMD0x00
#define SMI_CMD_BUSY BIT(15)
#define SMI_CMD_CLAUSE_22 BIT(12)
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
index 5ad130c3da43..0876aec7328c 100644
--- a/drivers/net/phy/bcm-phy-lib.c
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -346,10 +346,6 @@ void bcm_phy_get_strings(struct phy_device *phydev, u8
*data)
}
EXPORT_SYMBOL_GPL(bcm_phy_get_strings);
-#ifndef UINT64_MAX
-#define UINT64_MAX (u64)(~((u64)0))
-#endif
-
/* Caller is supposed to provide appropriate storage for the library code to
* access the shadow copy
*/
@@ -362,7 +358,7 @@ static u64 bcm_phy_get_stat(struct phy_device *phydev, u64
*shadow,
val = phy_read(phydev, stat.reg);
if (val < 0) {
- ret = UINT64_MAX;
+ ret = U64_MAX;
} else {
val >>= stat.shift;
val = val & ((1 << stat.bits) - 1);
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 25e2a099b71c..b8f57e9b9379 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1482,9 +1482,6 @@ static void marvell_get_strings(struct phy_device
*phydev, u8 *data)
}
}
-#ifndef UINT64_MAX
-#define UINT64_MAX (u64)(~((u64)0))
-#endif
static u64 marvell_get_stat(struct phy_device *phydev, int i)
{
struct marvell_hw_stat stat = marvell_hw_stats[i];
@@ -1494,7 +1491,7 @@ static u64 marvell_get_stat(struct phy_device *phydev,
int i)
val = phy_read_paged(phydev, stat.page, stat.reg);
if (val < 0) {
- ret = UINT64_MAX;
+ ret = U64_MAX;
} else {
val = val & ((1 << stat.bits) - 1);
priv->stats[i] += val;
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f41b224a9cdb..de31c5170a5b 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -650,9 +650,6 @@ static void kszphy_get_strings(struct phy_device *phydev,
u8 *data)
}
}
-#ifndef UINT64_MAX
-#define UINT64_MAX (u64)(~((u64)0))
-#endif
static u64 kszphy_get_stat(struct phy_device *phydev, int i)
{
struct kszphy_hw_stat stat = kszphy_hw_stats[i];
@@ -662,7 +659,7 @@ static u64 kszphy_get_stat(struct phy_device *phydev, int i)
val = phy_read(phydev, stat.reg);
if (val < 0) {
- ret = UINT64_MAX;
+ ret = U64_MAX;
} else {
val = val & ((1 << stat.bits) - 1);
priv->stats[i] += val;
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index be399d645224..c328208388da 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -168,9 +168,6 @@ static void smsc_get
[PATCH] clk: qcom: gdsc: Add support to poll CFG register to check GDSC state
From: Amit Nischal
The default behavior of the GDSC enable/disable sequence is to
poll the status bits of either the actual GDSCR or the
corresponding HW_CTRL registers.
On targets which have support for a CFG_GDSCR register, the
status bits might not show the correct state of the GDSC,
especially in the disable sequence, where the status bit
will be cleared even before the core is completely power
collapsed. On targets with this issue, poll the power on/off
bits in the CFG_GDSCR register instead to correctly determine
the GDSC state.
Signed-off-by: Amit Nischal
Signed-off-by: Taniya Das
---
drivers/clk/qcom/gdsc.c | 42 ++
drivers/clk/qcom/gdsc.h | 1 +
2 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index a4f3580..f8a9501 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -32,6 +32,11 @@
#define SW_COLLAPSE_MASK BIT(0)
#define GMEM_CLAMP_IO_MASK BIT(0)
+/* CFG_GDSCR */
+#define GDSC_POWER_UP_COMPLETE BIT(16)
+#define GDSC_POWER_DOWN_COMPLETE BIT(15)
+#define CFG_GDSCR_OFFSET 0x4
+
/* Wait 2^n CXO cycles between all states. Here, n=2 (4 cycles). */
#define EN_REST_WAIT_VAL (0x2 << 20)
#define EN_FEW_WAIT_VAL(0x8 << 16)
@@ -44,15 +49,28 @@
#define domain_to_gdsc(domain) container_of(domain, struct gdsc, pd)
-static int gdsc_is_enabled(struct gdsc *sc, unsigned int reg)
+static int gdsc_is_enabled(struct gdsc *sc, bool en)
{
+ unsigned int reg;
u32 val;
int ret;
+ if (sc->flags & POLL_CFG_GDSCR)
+ reg = sc->gdscr + CFG_GDSCR_OFFSET;
+ else
+ reg = sc->gds_hw_ctrl ? sc->gds_hw_ctrl : sc->gdscr;
+
ret = regmap_read(sc->regmap, reg, &val);
if (ret)
return ret;
+ if (sc->flags & POLL_CFG_GDSCR) {
+ if (en)
+ return !!(val & GDSC_POWER_UP_COMPLETE);
+ else
+ return !(val & GDSC_POWER_DOWN_COMPLETE);
+ }
+
return !!(val & PWR_ON_MASK);
}
@@ -63,17 +81,17 @@ static int gdsc_hwctrl(struct gdsc *sc, bool en)
return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK, val);
}
-static int gdsc_poll_status(struct gdsc *sc, unsigned int reg, bool en)
+static int gdsc_poll_status(struct gdsc *sc, bool en)
{
ktime_t start;
start = ktime_get();
do {
- if (gdsc_is_enabled(sc, reg) == en)
+ if (gdsc_is_enabled(sc, en) == en)
return 0;
} while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
- if (gdsc_is_enabled(sc, reg) == en)
+ if (gdsc_is_enabled(sc, en) == en)
return 0;
return -ETIMEDOUT;
@@ -83,7 +101,6 @@ static int gdsc_toggle_logic(struct gdsc *sc, bool en)
{
int ret;
u32 val = en ? 0 : SW_COLLAPSE_MASK;
- unsigned int status_reg = sc->gdscr;
ret = regmap_update_bits(sc->regmap, sc->gdscr, SW_COLLAPSE_MASK, val);
if (ret)
@@ -100,8 +117,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, bool en)
return 0;
}
- if (sc->gds_hw_ctrl) {
- status_reg = sc->gds_hw_ctrl;
+ if (sc->gds_hw_ctrl)
/*
* The gds hw controller asserts/de-asserts the status bit soon
* after it receives a power on/off request from a master.
@@ -113,9 +129,8 @@ static int gdsc_toggle_logic(struct gdsc *sc, bool en)
* and polling the status bit.
*/
udelay(1);
- }
- return gdsc_poll_status(sc, status_reg, en);
+ return gdsc_poll_status(sc, en);
}
static inline int gdsc_deassert_reset(struct gdsc *sc)
@@ -222,8 +237,6 @@ static int gdsc_disable(struct generic_pm_domain *domain)
/* Turn off HW trigger mode if supported */
if (sc->flags & HW_CTRL) {
- unsigned int reg;
-
ret = gdsc_hwctrl(sc, false);
if (ret < 0)
return ret;
@@ -235,8 +248,7 @@ static int gdsc_disable(struct generic_pm_domain *domain)
*/
udelay(1);
- reg = sc->gds_hw_ctrl ? sc->gds_hw_ctrl : sc->gdscr;
- ret = gdsc_poll_status(sc, reg, true);
+ ret = gdsc_poll_status(sc, true);
if (ret)
return ret;
}
@@ -258,7 +270,6 @@ static int gdsc_init(struct gdsc *sc)
{
u32 mask, val;
int on, ret;
- unsigned int reg;
/*
* Disable HW trigger: collapse/restore occur based on registers writes.
@@ -279,8 +290,7 @@ static int gdsc_init(struct gdsc *sc)
return ret;
}
- reg = sc->gds_hw_ctrl ? sc->gds_hw_ctrl : sc->gdscr;
- on = gdsc_is_enabled(sc, reg);
+ on = gdsc_is_enabl
Re: [PATCH v4 1/5] efi: Export boot-services code and data as debugfs-blobs
On 27 April 2018 at 10:13, Hans de Goede wrote: > Hi, > > > On 26-04-18 23:35, Ard Biesheuvel wrote: >> >> On 26 April 2018 at 23:02, Hans de Goede wrote: >>> >>> Hi, >>> >>> >>> On 26-04-18 18:51, Ard Biesheuvel wrote: On 26 April 2018 at 14:06, Hans de Goede wrote: > > > Sometimes it is useful to be able to dump the efi boot-services code > and > data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, > but only if efi=debug is passed on the kernel-commandline as this > requires > not freeing those memory-regions, which costs 20+ MB of RAM. > > Reviewed-by: Greg Kroah-Hartman > Signed-off-by: Hans de Goede > --- > Changes in v4: > -Add new EFI_BOOT_SERVICES flag and use it to determine if the > boot-services >memory segments are available (and thus if it makes sense to > register > the >debugfs bits for them) > > Changes in v2: > -Do not call pr_err on debugfs call failures > --- >arch/x86/platform/efi/efi.c| 1 + >arch/x86/platform/efi/quirks.c | 4 +++ >drivers/firmware/efi/efi.c | 53 > ++ >include/linux/efi.h| 1 + >4 files changed, 59 insertions(+) > > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c > index 9061babfbc83..568b7ee3d323 100644 > --- a/arch/x86/platform/efi/efi.c > +++ b/arch/x86/platform/efi/efi.c > @@ -208,6 +208,7 @@ int __init efi_memblock_x86_reserve_range(void) >efi.memmap.desc_version); > > memblock_reserve(pmap, efi.memmap.nr_map * > efi.memmap.desc_size); > + set_bit(EFI_BOOT_SERVICES, &efi.flags); > I think it would be better if the flag conveys whether boot services regions are being preserved, because they will always exist when EFI_BOOT is set. The name should then reflect that as well, e.g., EFI_PRESERVE_BS_REGIONS. >>> >>> >>> >>> Ok, I will rename the flag to EFI_PRESERVE_BS_REGIONS for v5 >>> (I'm going to wait a bit with sending out v5 to give others a change >>> to comment on v4). >>> > return 0; >} > diff --git a/arch/x86/platform/efi/quirks.c > b/arch/x86/platform/efi/quirks.c > index 36c1f8b9f7e0..16bdb9e3b343 100644 > --- a/arch/x86/platform/efi/quirks.c > +++ b/arch/x86/platform/efi/quirks.c > @@ -376,6 +376,10 @@ void __init efi_free_boot_services(void) > int num_entries = 0; > void *new, *new_md; > > + /* Keep all regions for /sys/kernel/debug/efi */ > + if (efi_enabled(EFI_DBG)) > + return; > + Why is this only necessary when EFI_DBG is enabled? How are you ensuring that the firmware is still in memory when the subsequent patches start relying on that? >>> >>> >>> >>> The 2nd patch in this series makes init/main.c call >>> efi_check_for_embedded_firmwares() before efi_free_boot_services(), >>> efi_check_for_embedded_firmwares() then walks the dmi_system_id-s >>> "registered" (its a static list) by drivers and if their is a dmi_match >>> searches for the firmware described by the dmi_system_id.driver_data >>> ptr. If a firmware gets found it gets memdup-ed, so that we do not >>> have to keep all of the boot-services code around. >>> >> >> Right, thanks for clearing that up. >> >> So that means that preserving the boot regions is really only >> necessary if you want to inspect them via debugfs, and the firmware >> loader does not rely on that. I missed that part. >> >> That means the only reason we have the new flag is to ensure that the >> shared debugfs code only exposes the boot services regions if they >> were preserved to begin with by the arch code, right? > > > Mostly right, since we have the flag now anyways I'm also using > it as a condition to call efi_check_for_embedded_firmwares(), > efi_check_for_embedded_firmwares() needs to happen after mm_init() (*) > and on non x86 the boot-services code/data is long gone then so > there is nothing for efi_check_for_embedded_firmwares() to look at. > Ah, of course, yes that was the whole point. >> If so, after the flag rename: >> >> Acked-by: Ard Biesheuvel > > > I assume that the "mostly right" is good enough and I'm going to > add your Acked-by for the next version. Let me know if you've > any objections against that. > Yes that's fine.
Re: [PATCH v7 06/11] ARM: sunxi: Add initialization of CNTVOFF
Hello Maxime,
Thanks for your review.
On Mon, 23 Apr 2018 10:16:09 +0200
Maxime Ripard wrote:
> On Fri, Apr 20, 2018 at 11:10:17PM +0200, Mylène Josserand wrote:
> > Add the initialization of CNTVOFF for sun8i-a83t.
> >
> > For boot CPU, create a new machine that handles this
> > function's call in an "init_early" callback. We need to initialize
> > CNTVOFF before the arch timer's initialization otherwise, it will
> > not be taken into account and fails to boot correctly.
> > Because of that, this function can't be called in SMP's early_initcall
> > function which is called after timer's init.
> >
> > For secondary CPUs, add this function into secondary_startup
> > assembly entry.
> >
> > Signed-off-by: Mylène Josserand
> > ---
> > arch/arm/mach-sunxi/headsmp.S | 1 +
> > arch/arm/mach-sunxi/sunxi.c | 20 +++-
> > 2 files changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
> > index 37dc772701f3..32d76be98541 100644
> > --- a/arch/arm/mach-sunxi/headsmp.S
> > +++ b/arch/arm/mach-sunxi/headsmp.S
> > @@ -71,6 +71,7 @@ ENDPROC(sunxi_mc_smp_cluster_cache_enable)
> >
> > ENTRY(sunxi_mc_smp_secondary_startup)
> > bl sunxi_mc_smp_cluster_cache_enable
> > + bl secure_cntvoff_init
> > b secondary_startup
> > ENDPROC(sunxi_mc_smp_secondary_startup)
> >
> > diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> > index 5e9602ce1573..ddc439f6269b 100644
> > --- a/arch/arm/mach-sunxi/sunxi.c
> > +++ b/arch/arm/mach-sunxi/sunxi.c
> > @@ -16,6 +16,7 @@
> > #include
> >
> > #include
> > +#include
> >
> > static const char * const sunxi_board_dt_compat[] = {
> > "allwinner,sun4i-a10",
> > @@ -62,7 +63,6 @@ MACHINE_END
> > static const char * const sun8i_board_dt_compat[] = {
> > "allwinner,sun8i-a23",
> > "allwinner,sun8i-a33",
> > - "allwinner,sun8i-a83t",
> > "allwinner,sun8i-h2-plus",
> > "allwinner,sun8i-h3",
> > "allwinner,sun8i-r40",
> > @@ -75,6 +75,24 @@ DT_MACHINE_START(SUN8I_DT, "Allwinner sun8i Family")
> > .dt_compat = sun8i_board_dt_compat,
> > MACHINE_END
> >
> > +void __init sun8i_cntvoff_init(void)
> > +{
> > +#ifdef CONFIG_SMP
> > + secure_cntvoff_init();
> > +#endif
> > +}
> > +
> > +static const char * const sun8i_cntvoff_board_dt_compat[] = {
> > + "allwinner,sun8i-a83t",
> > + NULL,
> > +};
> > +
> > +DT_MACHINE_START(SUN8I_CNTVOFF_DT, "Allwinner sun8i-a83t board")
>
> This name still doesn't really make much sense. It's an A83t, that's
> it.
True, I forgot this one, sorry.
>
> Apart from the other minor comment I had, and once that name has been
> fixed:
> Acked-by: Maxime Ripard
>
> Maxime
>
Thank you!
Best regards,
--
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options
On Thu 26-04-18 18:52:05, Mikulas Patocka wrote: > > > On Fri, 27 Apr 2018, Michael S. Tsirkin wrote: [...] > >But assuming it's important to control this kind of > >fault injection to be controlled from > >a dedicated menuconfig option, why not the rest of > >faults? > > The injected faults cause damage to the user, so there's no point to > enable them by default. vmalloc fallback should not cause any damage > (assuming that the code is correctly written). But you want to find those bugs which would BUG_ON easier, so there is a risk of harm IIUC and this is not much different than other fault injecting paths. -- Michal Hocko SUSE Labs
Re: [PATCH v7 08/11] ARM: sun9i: smp: Add is_a83t field
Hello,
On Mon, 23 Apr 2018 10:14:23 +0200
Maxime Ripard wrote:
> On Fri, Apr 20, 2018 at 11:10:19PM +0200, Mylène Josserand wrote:
> > To prepare the support of sun8i-a83t, add a field in the smp_data
> > structure to know if we are on sun9i-a80 or sun8i-a83t.
> >
> > Add also a global variable to retrieve which architecture we are
> > having.
> >
> > Signed-off-by: Mylène Josserand
> > ---
> > arch/arm/mach-sunxi/mc_smp.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> > index 03f021d0c73e..48e5f4db64b6 100644
> > --- a/arch/arm/mach-sunxi/mc_smp.c
> > +++ b/arch/arm/mach-sunxi/mc_smp.c
> > @@ -74,6 +74,7 @@ static void __iomem *sram_b_smp_base;
> >
> > extern void sunxi_mc_smp_secondary_startup(void);
> > extern void sunxi_mc_smp_resume(void);
> > +static int is_a83t;
> >
> > static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int
> > cluster)
> > {
> > @@ -624,6 +625,7 @@ struct sunxi_mc_smp_nodes {
> > struct sunxi_mc_smp_data {
> > const char *enable_method;
> > int (*get_smp_nodes)(struct sunxi_mc_smp_nodes *nodes);
> > + int is_a83t;
>
> This can be made a boolean.
>
> Maxime
>
ACK. It will be fixed in next version.
Best regards,
--
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent
On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote:
> Currently function debugfs_create_dir() creates a new
> directory in the debugfs (usually mounted /sys/kernel/debug)
> with permission rwxr-xr-x. This is hard coded.
>
> Change this to use the parent directory permission.
>
> Fixes: edac65eaf8d5c ("debugfs: take mode-dependent parts of
> debugfs_get_inode() into callers")
> Signed-off-by: Thomas Richter
> Cc: Greg Kroah-Hartman
> ---
> fs/debugfs/inode.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
> index 13b01351dd1c..80618330d86a 100644
> --- a/fs/debugfs/inode.c
> +++ b/fs/debugfs/inode.c
> @@ -512,7 +512,10 @@ struct dentry *debugfs_create_dir(const char *name,
> struct dentry *parent)
> if (unlikely(!inode))
> return failed_creating(dentry);
>
> - inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
> + if(!parent)
> + parent = debugfs_mount->mnt_root;
> + inode->i_mode = S_IFDIR | (d_inode(parent)->i_mode
> +& (S_IRWXU | S_IRWXG));
> inode->i_op = &simple_dir_inode_operations;
> inode->i_fop = &simple_dir_operations;
>
This looks ok, but is it going to change the permissions of existing
stuff in ways that might breaks things, right?
Have you done a before/after comparison?
thanks,
greg k-h
Re: stable 4.16.5 hmm build error
On Fri, Apr 27, 2018 at 10:17:42AM +0200, Arnd Bergmann wrote:
> On Fri, Apr 27, 2018 at 9:30 AM, Greg Kroah-Hartman
> wrote:
> > On Fri, Apr 27, 2018 at 02:19:24AM +0300, Михаил Носов wrote:
> >> Oh. Yes. Tag v4.16.5 without commit
> >> 9d8a463a7016e9e5578a561588a18acef139919c.
> >> It's in v4.17-rc1/2.
> >> Thank you.
> >
> > That patch does not apply to the stable trees. I'm also confused by the
> > lack of "real" git commit ids that are being referred to here, that
> > commit refers to one that is not valid.
> >
> >> 2018-04-27 0:52 GMT+03:00 Randy Dunlap :
> >>
> >> > https://bugzilla.kernel.org/show_bug.cgi?id=199515
> >> >
> >> > kernel/fork.o: In function `__mmdrop':
> >> > /kernel/build_kernel/linux-4.16.4/kernel/fork.c:600: undefined reference
> >> > to `hmm_mm_destroy'
> >
> > What .config is creating this? I have not seen any kbuild reports of
> > this in the past.
>
> I only got this through randconfig builds on mainline.
>
> >> >
> >> > "It is also reproduced in linux-4.16.5"
> >> >
> >> >
> >> > There have been a few attempts to fix this build error. The kernel
> >> > mainline
> >> > repo seems to have it fixed, but it looks to me like Arnd's latest patch
> >> > (9d8a463a7016e: "mm/hmm: fix header file if/else/endif maze, again")
> >> > was mis-merged to 4.16.5 stable.
> >> >
> >> > Please take a look. Do you already have a fixup for this?
>
> Jérôme initially created
>
> 6b368cd4a44c ("mm/hmm: avoid bloating arch that do not make use of HMM")
>
> which is part of v4.16. He noticed a build error that he fixed up with commit
>
> b28b08de436a ("mm/hmm: fix header file if/else/endif maze")
>
> which you backported as 25df8b83e867 into linux-4.16.y after v4.16.4.
> After that originally landed in mainline, I found another build error that
> I fixed with commit
>
> 9d8a463a7016 ("mm/hmm: fix header file if/else/endif maze, again")
Why does that commit reference:
Fixes: 8900d06a277a ("mm/hmm: fix header file if/else/endif maze")
when there is no such commit in the tree?
> This fixes the issue that Randy is reporting now, please add that into
> v4.16.5.
I tried, but it does not apply cleanly:
$ p1 < ../mm-hmm-fix-header-file-if-else-endif-maze-again.patch
checking file include/linux/hmm.h
Hunk #1 FAILED at 376.
Hunk #2 succeeded at 498 (offset -52 lines).
1 out of 2 hunks FAILED
Am I missing some other commit that went in inbetween the above patches?
thanks,
greg k-h
Re: [PATCH 2/2] sched/fair: Avoid calling sync_entity_load_avg() unnecessarily
Hi Viresh,
On 04/26/2018 12:30 PM, Viresh Kumar wrote:
Call sync_entity_load_avg() directly from find_idlest_cpu() instead of
select_task_rq_fair(), as that's where we need to use task's utilization
value. And call sync_entity_load_avg() only after making sure sched
domain spans over one of the allowed CPUs for the task.
Signed-off-by: Viresh Kumar
The patch looks correct to me but we want to have the waking task synced
against its previous rq also for EAS, i.e. for
find_energy_efficient_cpu() which will sit next to find_idlest_cpu().
https://marc.info/?l=linux-kernel&m=152302907327168&w=2
The comment on top of the if condition would have to be changed though.
I would suggest we leave the call to sync_entity_load_avg() in the slow
path of strf() so that we're not forced to call it in
find_energy_efficient_cpu().
---
kernel/sched/fair.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 84fc74ddbd4b..5b1b4f91f132 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6199,6 +6199,13 @@ static inline int find_idlest_cpu(struct sched_domain
*sd, struct task_struct *p
if (!cpumask_intersects(sched_domain_span(sd), &p->cpus_allowed))
return prev_cpu;
+ /*
+* We need task's util for capacity_spare_wake, sync it up to prev_cpu's
+* last_update_time.
+*/
+ if (!(sd_flag & SD_BALANCE_FORK))
+ sync_entity_load_avg(&p->se);
+
while (sd) {
struct sched_group *group;
struct sched_domain *tmp;
@@ -6651,15 +6658,6 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu,
int sd_flag, int wake_f
if (unlikely(sd)) {
/* Slow path */
-
- /*
-* We're going to need the task's util for capacity_spare_wake
-* in find_idlest_group. Sync it up to prev_cpu's
-* last_update_time.
-*/
- if (!(sd_flag & SD_BALANCE_FORK))
- sync_entity_load_avg(&p->se);
-
new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag);
} else if (sd_flag & SD_BALANCE_WAKE) { /* XXX always ? */
/* Fast path */
Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"
Hi Jan, At 04/27/2018 03:21 PM, Jan Beulich wrote: Hello, I've just stumbled across this commit, and I'm wondering if that's actually correct (I too have at least one system where such IDs are reported in MADT): For offline/absent CPUs, the firmware may not know the APIC IDs The MADT table is not reasonable, the Local APIC entries(xAPIC/x2APIC) in MADT is not always correct as OS want. So, we should do this sanity check. at the point MADT is built, so I think it is quite reasonable to put ~0 in there. The ACPID spec specifically calls out that the IDs must not change across sleep states, which implies to me that they may change across an offline period of a CPU. IOW I think such entries still need to contribute to the count of disabled CPUs. Aha, there are no CPU devices which will map it's physical ID to the illegal number 0x, So it will never be used. BTW, Limiting the number of the disabled CPUs is also a goal. Thanks, dou I notice a similar change has been done for the xAPIC case a while ago by you, Thomas. Jan
Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h6: add device tree nodes for MMC controllers
于 2018年4月27日 GMT+08:00 上午12:45:38, Andre Przywara 写到:
>Hi,
>
>On 26/04/18 15:07, Icenowy Zheng wrote:
>> The Allwinner H6 SoC have 3 MMC controllers.
>>
>> Add device tree nodes for them.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56
>
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> index 4debc3962830..3cbfc035c979 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> @@ -124,12 +124,68 @@
>> interrupt-controller;
>> #interrupt-cells = <3>;
>>
>> +mmc0_pins: mmc0-pins {
>> +pins = "PF0", "PF1", "PF2", "PF3",
>> + "PF4", "PF5";
>> +function = "mmc0";
>> +drive-strength = <30>;
>> +bias-pull-up;
>> +};
>> +
>> +mmc2_pins: mmc2-pins {
>> +pins = "PC1", "PC4", "PC5", "PC6",
>> + "PC7", "PC8", "PC9", "PC10",
>> + "PC11", "PC12", "PC13", "PC14";
>> +function = "mmc2";
>> +drive-strength = <30>;
>> +bias-pull-up;
>> +};
>> +
>> uart0_ph_pins: uart0-ph {
>> pins = "PH0", "PH1";
>> function = "uart0";
>> };
>> };
>>
>> +mmc0: mmc@402 {
>> +compatible = "allwinner,sun50i-h6-mmc";
>
>This should be:
> compatible = "allwinner,sun50i-h6-mmc",
>"allwinner,sun50i-a64-mmc";
I'm intended to not add A64 compatible, as
H6 is a quite new design
(new process) and there might be different behavior, even on mmc0/1.
>
>> +reg = <0x0402 0x1000>;
>> +clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
>> +clock-names = "ahb", "mmc";
>> +resets = <&ccu RST_BUS_MMC0>;
>> +reset-names = "ahb";
>> +interrupts = ;
>> +status = "disabled";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +};
>> +
>> +mmc1: mmc@4021000 {
>> +compatible = "allwinner,sun50i-h6-mmc";
>
>same here
>
>> +reg = <0x04021000 0x1000>;
>> +clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
>> +clock-names = "ahb", "mmc";
>> +resets = <&ccu RST_BUS_MMC1>;
>> +reset-names = "ahb";
>> +interrupts = ;
>> +status = "disabled";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +};
>> +
>> +mmc2: mmc@4022000 {
>> +compatible = "allwinner,sun50i-h6-emmc";
>
>and here:
> compatible = "allwinner,sun50i-h6-emmc",
>"allwinner,sun50i-a64-emmc";
MMC2 on H6 has EMCE capability, so surely there should
only be H6 compatible, and no A64 one.
>
>The rest looks correct to me.
>
>Cheers,
>Andre.
>
>> +reg = <0x04022000 0x1000>;
>> +clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
>> +clock-names = "ahb", "mmc";
>> +resets = <&ccu RST_BUS_MMC2>;
>> +reset-names = "ahb";
>> +interrupts = ;
>> +status = "disabled";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +};
>> +
>> uart0: serial@500 {
>> compatible = "snps,dw-apb-uart";
>> reg = <0x0500 0x400>;
>>
Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers
Hi Arnd, On Friday 27 April 2018 01:22 PM, Arnd Bergmann wrote: > On Fri, Apr 27, 2018 at 4:28 AM, David Lechner wrote: >> On 04/26/2018 12:31 PM, Rich Felker wrote: >>> >>> On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote: From: Bartosz Golaszewski This is a follow to my series[1] the aim of which was to introduce device tree support for early platform devices. It was received rather negatively. Aside from using device tree to pass implementation specific details to the system, two important concerns were raised: no probe deferral support and the fact that currently the early devices never get converted to actual platform drivers. This series is a proof-of-concept that's trying to address those issues. The only user of the current version of early platform drivers is the SuperH architecture. If this series eventually gets merged, we could simply replace the other solution. >>> >>> >>> Looking at a quick output of: >>> >>> grep -r -A10 early_devices[[] arch/sh/kernel/ >>> >>> it looks like all of the existing early platform devices are serial >>> ports, clocks, and clocksources. The switch to device tree should pick >>> them all up from CLK_OF_DECLARE, TIMER_OF_DECLARE, and >>> EARLYCON_DECLARE. Until that's complete, the existing code works >>> as-is. I don't see what problem you're trying to solve. >> >> >> The problem for us is that clk maintainers don't want new drivers to use >> CLK_OF_DECLARE and instead use platform devices. I have just written such >> a new driver that is shared by 6 different SoCs. For some combinations of >> SoCs and clocks, using a platform device is fine but on others we need to >> register early, so the drivers now have to handle both cases, which is >> kind of messy and fragile. If there is a generic way to register platform >> devices early, then the code is simplified because we only have to handle >> one method of registering the clocks instead of two. > > The early_platform code is certainly not a way to make things simpler, > it just adds one more way of doing the same thing that OF_CLK_DECLARE > already does. We removed the last early_platform users on ARM a few > years ago, and I would hope to leave it like that. > > I haven't seen the discussion about your clock drivers, but I know that > usually only a very small subset of the clocks on an SoC are needed > that 'early', and you should use a regular platform driver for the rest. Its true that the subset is small, but they are either PLL bypass clocks or clocks derived out of the main clock gate controller on the Soc (DaVinci PSC). So we need some non-platform-device based initialization support in the two main clock drivers used on mach-davinci anyway. > Can you elaborate on which devices need to access your clocks before > you are able to initialize the clk driver through the regular platform_driver > framework? Do any of these need complex interactions with the clk > subsystem, or do you just need to ensure they are turned on? Its just the timer IP. There is no complex interaction, just need to ensure that the clock is registered with the framework and also switched on when there is a gate clock. The latest attempt by David for this was posted last night here: https://lkml.org/lkml/2018/4/26/1093 Thanks, Sekhar
Re: [linux-sunxi] [PATCH 1/3] mmc: sunxi: add support for the MMC controller on H6
于 2018年4月27日 GMT+08:00 上午12:45:24, Andre Przywara 写到:
>Hi,
>
>On 26/04/18 15:07, Icenowy Zheng wrote:
>> The new Allwinner H6 SoC have 3 MMC controllers. The first and second
>> ones are similar to the ones on A64, but the third one adds EMCE
>> (Embedded Crypto Engine) support which does hardware transparent
>crypto
>> on the eMMC.
>>
>> As we still do not have support for EMCE, and the support of it is
>> disabled by defualt, we just duplicate the A64 mmc configurations and
>> change the compatible string.
>
>So if the A64 MMC part is compatible, we should express it like this:
>
>> Signed-off-by: Icenowy Zheng
>> ---
>> Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 2 ++
>> drivers/mmc/host/sunxi-mmc.c| 16
>
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>> index 132e0007d7d6..e6aa5c7a5e12 100644
>> --- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>> @@ -16,6 +16,8 @@ Required properties:
>> * "allwinner,sun9i-a80-mmc"
>> * "allwinner,sun50i-a64-emmc"
>> * "allwinner,sun50i-a64-mmc"
>> + * "allwinner,sun50i-h6-emmc"
>> + * "allwinner,sun50i-h6-mmc"
>
>This should be changed to:
>
> * "allwinner,sun50i-h6-emmc", "allwinner,sun50i-a64-emmc"
> * "allwinner,sun50i-h6-mmc", "allwinner,sun50i-a64-mmc"
This list shouldn't list pairs, and as I said in the reply,
these pairs are not valid.
>
>> - reg : mmc controller base registers
>> - clocks : a list with 4 phandle + clock specifier pairs
>> - clock-names : must contain "ahb", "mmc", "output" and "sample"
>> diff --git a/drivers/mmc/host/sunxi-mmc.c
>b/drivers/mmc/host/sunxi-mmc.c
>> index 97c6b79b7d6f..05e2b5fd7aa4 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -1168,6 +1168,20 @@ static const struct sunxi_mmc_cfg
>sun50i_a64_emmc_cfg = {
>> .can_calibrate = true,
>> };
>>
>> +static const struct sunxi_mmc_cfg sun50i_h6_cfg = {
>> +.idma_des_size_bits = 16,
>> +.clk_delays = NULL,
>> +.can_calibrate = true,
>> +.mask_data0 = true,
>> +.needs_new_timings = true,
>> +};
>> +
>> +static const struct sunxi_mmc_cfg sun50i_h6_emmc_cfg = {
>> +.idma_des_size_bits = 13,
>> +.clk_delays = NULL,
>> +.can_calibrate = true,
>> +};
>> +
>
>... and then we don't need those changes ...
>
>> static const struct of_device_id sunxi_mmc_of_match[] = {
>> { .compatible = "allwinner,sun4i-a10-mmc", .data = &sun4i_a10_cfg
>},
>> { .compatible = "allwinner,sun5i-a13-mmc", .data = &sun5i_a13_cfg
>},
>> @@ -1176,6 +1190,8 @@ static const struct of_device_id
>sunxi_mmc_of_match[] = {
>> { .compatible = "allwinner,sun9i-a80-mmc", .data = &sun9i_a80_cfg
>},
>> { .compatible = "allwinner,sun50i-a64-mmc", .data = &sun50i_a64_cfg
>},
>> { .compatible = "allwinner,sun50i-a64-emmc", .data =
>&sun50i_a64_emmc_cfg },
>> +{ .compatible = "allwinner,sun50i-h6-mmc", .data = &sun50i_h6_cfg
>},
>> +{ .compatible = "allwinner,sun50i-h6-emmc", .data =
>&sun50i_h6_emmc_cfg },
>
>... and those, at least yet.
>Should we ever extend the driver to support the EMCE, we can add them
>at
>this occasion.
>
>So this patch would just add the compatible pairs to the binding doc.
>
>Cheers,
>Andre.
>
>> { /* sentinel */ }
>> };
>> MODULE_DEVICE_TABLE(of, sunxi_mmc_of_match);
>>
>
>___
>linux-arm-kernel mailing list
>linux-arm-ker...@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 02/17] dt-bindings: display: renesas: du: Document the R8A77965 bindings
Hi Laurent, On 26/04/18 21:10, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. > > On Thursday, 26 April 2018 19:57:32 EEST Kieran Bingham wrote: >> Ahem - this one seems to have lost it's commit message. >> >> Apologies :) > > Apart from that, this looks good to me. > > Reviewed-by: Laurent Pinchart > > and applied to my tree with the commit message > > Document the M3-N (r8a77965) SoC in the R-Car DU bindings > That's perfect, thanks - and saves me sending a v1.1 Regards Kieran > Let me know if you would like a different message. > >> On 26/04/18 17:53, Kieran Bingham wrote: >>> Signed-off-by: Kieran Bingham >>> --- >>> >>> Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt >>> b/Documentation/devicetree/bindings/display/renesas,du.txt index >>> a36a6e7ee54f..7c6854bd0a04 100644 >>> --- a/Documentation/devicetree/bindings/display/renesas,du.txt >>> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt >>> >>> @@ -13,6 +13,7 @@ Required Properties: >>> - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU >>> - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU >>> - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU >>> +- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU >>> - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU >>> - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU >>> >>> @@ -59,6 +60,7 @@ corresponding to each DU output. >>> >>> R8A7794 (R-Car E2) DPAD 0 DPAD 1 - - >>> R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS >>> 0 >>> R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 - >>> + R8A77965 (R-Car M3-N) DPAD 0 HDMI 0 LVDS 0 - >>> R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - - >>> R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 - > signature.asc Description: OpenPGP digital signature
Re: [PATCH net-next 1/2 v2] netns: restrict uevents
On Thu, Apr 26, 2018 at 07:35:47PM -0500, Eric W. Biederman wrote:
> Christian Brauner writes:
>
> > On Thu, Apr 26, 2018 at 12:10:30PM -0500, Eric W. Biederman wrote:
> >> Christian Brauner writes:
> >>
> >> > On Thu, Apr 26, 2018 at 11:47:19AM -0500, Eric W. Biederman wrote:
> >> >> Christian Brauner writes:
> >> >>
> >> >> > On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote:
> >> >> >> Christian Brauner writes:
> >> >> >>
> >> >> >> > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> > Bah. This code is obviously correct and probably wrong.
> >> >> >> >
> >> >> >> > How do we deliver uevents for network devices that are outside of
> >> >> >> > the
> >> >> >> > initial user namespace? The kernel still needs to deliver those.
> >> >> >> >
> >> >> >> > The logic to figure out which network namespace a device needs to
> >> >> >> > be
> >> >> >> > delivered to is is present in kobj_bcast_filter. That logic will
> >> >> >> > almost
> >> >> >> > certainly need to be turned inside out. Sign not as easy as I
> >> >> >> > would
> >> >> >> > have hoped.
> >> >> >> >
> >> >> >> > My first patch that we discussed put additional filtering logic
> >> >> >> > into kobj_bcast_filter for that very reason. But I can move that
> >> >> >> > logic
> >> >> >> > out and come up with a new patch.
> >> >> >>
> >> >> >> I may have mis-understood.
> >> >> >>
> >> >> >> I heard and am still hearing additional filtering to reduce the
> >> >> >> places
> >> >> >> the packet is delievered.
> >> >> >>
> >> >> >> I am saying something needs to change to increase the number of
> >> >> >> places
> >> >> >> the packet is delivered.
> >> >> >>
> >> >> >> For the special class of devices that kobj_bcast_filter would apply
> >> >> >> to
> >> >> >> those need to be delivered to netowrk namespaces that are no longer
> >> >> >> on
> >> >> >> uevent_sock_list.
> >> >> >>
> >> >> >> So the code fundamentally needs to split into two paths. Ordinary
> >> >> >> devices that use uevent_sock_list. Network devices that are just
> >> >> >> delivered in their own network namespace.
> >> >> >>
> >> >> >> netlink_broadcast_filtered gets to go away completely.
> >> >> >
> >> >> > The split *might* make sense but I think you're wrong about removing
> >> >> > the
> >> >> > kobj_bcast_filter. The current filter doesn't operate on the uevent
> >> >> > socket in uevent_sock_list itself it rather operates on the sockets in
> >> >> > mc_list. And if socket in mc_list can have a different network
> >> >> > namespace
> >> >> > then the uevent_socket itself then your way won't work. That's why my
> >> >> > original patch added additional filtering in there. The way I see it
> >> >> > we
> >> >> > need something like:
> >> >>
> >> >> We already filter the sockets in the mc_list by network namespace.
> >> >
> >> > Oh really? That's good to know. I haven't found where in the code this
> >> > actually happens. I thought that when netlink_bind() is called anyone
> >> > could register themselves in mc_list.
> >>
> >> The code in af_netlink.c does:
> >> > static void do_one_broadcast(struct sock *sk,
> >> > struct netlink_broadcast_data *p)
> >> > {
> >> > struct netlink_sock *nlk = nlk_sk(sk);
> >> > int val;
> >> >
> >> > if (p->exclude_sk == sk)
> >> > return;
> >> >
> >> > if (nlk->portid == p->portid || p->group - 1 >= nlk->ngroups ||
> >> > !test_bit(p->group - 1, nlk->groups))
> >> > return;
> >> >
> >> > if (!net_eq(sock_net(sk), p->net)) {
> >> Here
> >> > if (!(nlk->flags & NETLINK_F_LISTEN_ALL_NSID))
> >> > return;
> >> ^^^ Here
> >> >
> >> > if (!peernet_has_id(sock_net(sk), p->net))
> >> > return;
> >> >
> >> > if (!file_ns_capable(sk->sk_socket->file, p->net->user_ns,
> >> > CAP_NET_BROADCAST))
> >> > return;
> >> > }
> >>
> >> Which if you are not a magic NETLINK_F_LISTEN_ALL_NSID socket filters
> >> you out if you are the wrong network namespace.
> >>
> >>
> >> >> When a packet is transmitted with netlink_broadcast it is only
> >> >> transmitted within a single network namespace.
> >> >>
> >> >> Even in the case of a NETLINK_F_LISTEN_ALL_NSID socket the skb is tagged
> >> >> with it's source network namespace so no confusion will result, and the
> >> >> permission checks have been done to make it safe. So you can safely
> >> >> ignore that case. Please ignore that case. It only needs to be
> >> >> considered if refactoring af_netlink.c
> >> >>
> >> >> When I added netlink_broadcast_filtered I imagined that we would need
> >> >> code that worked across network namespaces that worked for different
> >> >> namespaces. So it looked like we would need the level of granularity
> >> >> that you can get with netlink_broadcast_filtered. It turns o
Re: [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE
[ Dropping Roger He, his e-mail address seems to bounce ] On 2018-04-27 04:51 AM, zhoucm1 wrote: > On 2018年04月26日 23:06, Michel Dänzer wrote: >> From: Michel Dänzer >> >> When it's set, TTM tries to allocate huge pages if possible. > Do you mean original driver doesn't do this? > From the code, driver always try huge pages if > CONFIG_TRANSPARENT_HUGEPAGE is enabled. Right, before this change, TTM would do this unconditionally for all drivers. The point of this change is not to incur any huge page related overhead for drivers which can't take advantage of huge pages anyway. I'll try changing the commit log to make this clearer in v2. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Re: [PATCH v2 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive
Hi Eric, Thank you for the patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Eric-Dumazet/tcp-add-TCP_ZEROCOPY_RECEIVE-support-for-zerocopy-receive/20180427-122234 config: sh-rsk7269_defconfig (attached as .config) compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=sh All errors (new ones prefixed by >>): net/ipv4/tcp.o: In function `tcp_setsockopt': >> tcp.c:(.text+0x3f80): undefined reference to `zap_page_range' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: stable 4.16.5 hmm build error
On Fri, Apr 27, 2018 at 10:30 AM, Greg Kroah-Hartman
wrote:
> On Fri, Apr 27, 2018 at 10:17:42AM +0200, Arnd Bergmann wrote:
>> On Fri, Apr 27, 2018 at 9:30 AM, Greg Kroah-Hartman
>>
>> which you backported as 25df8b83e867 into linux-4.16.y after v4.16.4.
>> After that originally landed in mainline, I found another build error that
>> I fixed with commit
>>
>> 9d8a463a7016 ("mm/hmm: fix header file if/else/endif maze, again")
>
> Why does that commit reference:
> Fixes: 8900d06a277a ("mm/hmm: fix header file if/else/endif maze")
>
> when there is no such commit in the tree?
This must have happened when the commit that introduced it came through
the -mm tree and got a new commit ID between the time I sent the fix
and Linus picking up the patch from Andrew. I try to hand-edit the
'Fixes' line when I know it's a patch in -mm to say 'Fixes: mmotm ("...")'
but I missed that his time.
>> This fixes the issue that Randy is reporting now, please add that into
>> v4.16.5.
>
> I tried, but it does not apply cleanly:
> $ p1 < ../mm-hmm-fix-header-file-if-else-endif-maze-again.patch
> checking file include/linux/hmm.h
> Hunk #1 FAILED at 376.
> Hunk #2 succeeded at 498 (offset -52 lines).
> 1 out of 2 hunks FAILED
>
> Am I missing some other commit that went in inbetween the above patches?
There were several other commits from Jérôme inbetween. I don't
immediately see where the conflict came from, but as my patch is
basically a revert of Jérôme's, and it was working in v4.16.4, maybe
it's best if you drop the backport of b28b08de436a for now, let him
comment on whether we still need it. I had not seen the build error
he referred to in his commit and we know that it does cause a
new one.
Arnd
[PATCH] crypto: caam - fix size of RSA prime factor q
Fix a typo where size of RSA prime factor q is using the size of
prime factor p.
Cc: # 4.13+
Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2")
Fixes: 4a651b122adb ("crypto: caam - add support for RSA key form 3")
Reported-by: David Binderman
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caampkc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
index 6f990139f324..578ea63a3109 100644
--- a/drivers/crypto/caam/caampkc.c
+++ b/drivers/crypto/caam/caampkc.c
@@ -66,7 +66,7 @@ static void rsa_priv_f2_unmap(struct device *dev, struct
rsa_edesc *edesc,
struct caam_rsa_key *key = &ctx->key;
struct rsa_priv_f2_pdb *pdb = &edesc->pdb.priv_f2;
size_t p_sz = key->p_sz;
- size_t q_sz = key->p_sz;
+ size_t q_sz = key->q_sz;
dma_unmap_single(dev, pdb->d_dma, key->d_sz, DMA_TO_DEVICE);
dma_unmap_single(dev, pdb->p_dma, p_sz, DMA_TO_DEVICE);
@@ -83,7 +83,7 @@ static void rsa_priv_f3_unmap(struct device *dev, struct
rsa_edesc *edesc,
struct caam_rsa_key *key = &ctx->key;
struct rsa_priv_f3_pdb *pdb = &edesc->pdb.priv_f3;
size_t p_sz = key->p_sz;
- size_t q_sz = key->p_sz;
+ size_t q_sz = key->q_sz;
dma_unmap_single(dev, pdb->p_dma, p_sz, DMA_TO_DEVICE);
dma_unmap_single(dev, pdb->q_dma, q_sz, DMA_TO_DEVICE);
@@ -397,7 +397,7 @@ static int set_rsa_priv_f2_pdb(struct akcipher_request *req,
struct rsa_priv_f2_pdb *pdb = &edesc->pdb.priv_f2;
int sec4_sg_index = 0;
size_t p_sz = key->p_sz;
- size_t q_sz = key->p_sz;
+ size_t q_sz = key->q_sz;
pdb->d_dma = dma_map_single(dev, key->d, key->d_sz, DMA_TO_DEVICE);
if (dma_mapping_error(dev, pdb->d_dma)) {
@@ -472,7 +472,7 @@ static int set_rsa_priv_f3_pdb(struct akcipher_request *req,
struct rsa_priv_f3_pdb *pdb = &edesc->pdb.priv_f3;
int sec4_sg_index = 0;
size_t p_sz = key->p_sz;
- size_t q_sz = key->p_sz;
+ size_t q_sz = key->q_sz;
pdb->p_dma = dma_map_single(dev, key->p, p_sz, DMA_TO_DEVICE);
if (dma_mapping_error(dev, pdb->p_dma)) {
--
2.16.2
Re: moving affs + RDB partition support to staging?
OK guys, I am working from th ememory of a 74 year old with a severe head cold.
The filesystems were always limited to 2 TB since the seek command was signed 32
bit integer number of BYTEs. So block size has nothing to do with this 2TB
issue. That's something else in the descriptions.
The RDBs grew a block size and sector size concept in describing partitions. One
had to be a power of two multiple of the other, as I recall. The relationship
worked two ways. If you had a Fujitsu Magneto Optical drive with 2k physical
sectors you could still allocate space in virtual sectors, block sizes, of 512
bytes. Or you could use much larger blocks than sector size to cut down on the
unallocated blocks list. Of course, all OSs do that these days. With a single
unsigned 16 bit integer your address space would fill up a 32 GB with 512 byte
blocks. We could see this would blow out so we decribed block size and disk size
in blocks with 32 bit integers giving 4 TB of 1 BYTE blocks. Supposing the file
sizes stored are such as to support an 8k block size that means describing a
very large disk should be very easy, even if block size was a 16 bit unsigned
integer.
To carry this forward more accurately I'll have to dig up some old archival data
and see what it actually says. This isn't going to happen when I sit here
sniffling. Maybe in a few days I can dredge up the actual numbers. I seem to
remember at the time that without a 64 bit OS the disk addressing limit was 2
TB, since seeks were signed integers. The disk descriptions could be
considerably larger.
And before I forget there are two features of the RDBs that I heartily recommend
never implementing on Linux. They were good ideas at the time; but, times
changed. The RDBs are capable of storing a filesystem driver and some drive init
code for the plugin disk driver card. That is giving malware authors entirely
goo easy a shot at owning a machine. Martin S., I would strongly suggest that
going forward those two capabilities be removed from the RDB readers in AmigaOS
as well as Linux OS.
I also note that at one time the RDB parsing facility in Linux benefitted from
my hands on the code and handled the block size/sector size issues very nicely.
I had an 18 GB disk I wanted to be able to read on Linux. I seem to remember
somebody at one time had a "this doesn't make any real world sense" event and
had to be reminded that the real world was wider than he envisioned. I don't
know what has happened since then.
{^_^} Joanne Dow
On 20180426 04:08, Geert Uytterhoeven wrote:
Hi Martin,
CC jdow
On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
wrote:
You probably put your stick into a cave with ancient sleeping dragons :)
Added in linux-m68k mailing list, as they likely have an opinion on how
to treat affs + RDB partition support. Also added in Jens Axboe about
patching that RDB support broken with 2 TB or larger harddisks issue
which had been in Linux kernel for 6 years while a patch exists that to
my testing back then solves the issue.
While non-native Linux filesystem support (e.g. affs/isofs/...) could be
handled by FUSE, moving RDB partition support to staging is not an option,
as it is the only partitioning scheme that Amigas can boot from.
If there are bugs in the RDB parser that people run into, they should
be fixed.
If there are limitations in the RDB format on large disks, that's still not
a reason to move it to staging (hi msdos partitioning!).
Matthew Wilcox - 26.04.18, 04:57:
On Wed, Apr 25, 2018 at 10:30:29PM +0200, David Sterba wrote:
I had similar toughts some time ago while browsing the fs/
directory.
Access to the filesystem images can be reimplemented in FUSE, but
other than that, I don't think the in-kernel code would be missed.
It's hard to know how many users are there. I was curious eg. about
bfs, befs, coda or feevxfs, looked at the last commits and searched
around web if there are any mentions or user community. But as long
as there's somebody listed in MAINTAINERS, the above are not
candidates for moving to staging or deletion.
Yeah, it's pretty sad how few commits some of these filesystems have
had in recent years. One can argue that they're stable and don't need
to be fixed because they aren't broken, but I find it hard to believe
that any of them were better-implemented than ext2 which still sees
regular bugfixes.
Regarding affs there is a severe issue which is not in affs itself but
in the handling of Rigid Disk Block (RDB) partitions, the Amiga
partitioning standard, which is far more advanced than MBR: It overruns
for 2 TB or larger drives and then wraps over to the beginning of the
drive – I bet you can imagine what happens if you write to an area
larger than 2 TB. I learned this with an external 2TB RDB partitioned
harddisk back then, which I used for Sam440ep (a kind of successor for
old, classic Amiga hardware) backup + some Linux related stuff in
another partition.
Joanne Dow, a deve
Re: moving affs + RDB partition support to staging?
On 20180426 16:56, Finn Thain wrote:
On Thu, 26 Apr 2018, Geert Uytterhoeven wrote:
While non-native Linux filesystem support (e.g. affs/isofs/...) could be
handled by FUSE
Moving to FUSE is a great divide-and-conquer strategy for those who just
want the code to die and don't care about any of the data in that format.
If there is a maintainence burden that can be shared then it should be
shared -- until it can be established that there is no data of value in
that format.
moving RDB partition support to staging is not an option, as it is the
only partitioning scheme that Amigas can boot from.
Whether or not the original hardware is in use is mostly irrelevant.
As long as the old format is accessible using current hardware, the data
in that format remains accessible (to archivists, to curators, to your
decendents, etc).
If there are bugs in the RDB parser that people run into, they should be
fixed. If there are limitations in the RDB format on large disks, that's
still not a reason to move it to staging (hi msdos partitioning!).
This intrepid cyberunit is inclined to suggest that understanding the RDBs can
go a long way towards defining if there is a bug somewhere and whether it is in
the RDB description or its misuse.
There are some things RDBs can do that REALLY REALLY don't make sense until you
run across the situation which called for it creation. There are two variables
that suggest some blocks at the beginning and the end, respectively, of a
partition are not accessible by the OS. I have used these facilities to
"interleave" partitions and RDBs. I have built a disk which reserved about 128
512 byte blocks for RDBs plus filesystem code (which probably should be
abandoned) which embedded the RDBs describing the partition within the
partition. Then I reserved space at the end of the partition and embedded a
second partition in that space. As absurd as it sounds this had at one time a
decent use case. Disk space was an expensive premium in those days so wasting
space to get nice integer numbers in the disk description, which was phony for a
hard disk in any case, we allowed any numbers and if that went past the end of
the disk we reserved the necessary space so that it would never be used. The
space at the beginning of a partition was needed in any case because a one block
partition signature needed space at the start of the partition. It held the
filesystem's signature, OFS, AFS, SFS, etc.
There is also a good reason for allowing the anchor for the RDBs to start in any
of the first 16 blocks with a recommendation not to use block 0 as other FSs
used that. And we wanted to accommodate at least two different partition
description technologies to work on the disk. My code always placed the RDBs at
block 3.
I hope passing along some of this history will mitigate some fo the feelings
that RDBs are inherently flawed or full of bugs or whatnot. (Full pf security
holes is another story. DriveInit code and filesystem code have worried me from
day one.)
{^_^} Joanne
Re: [PATCH] nvme: unquiesce the queue before cleaup it
Hi Max
On 04/26/2018 06:23 PM, Max Gurtovoy wrote:
> Hi Jianchao,
> I actually tried this scenario with real HW and was able to repro the hang.
> Unfortunatly, after applying your patch I got NULL deref:
> BUG: unable to handle kernel NULL pointer dereference at 0014
> WARNING: CPU: 5 PID: 0 at block/blk-mq.c:526
> __blk_mq_complete_request+0x154/0x160
>
Could you please share the whole backtrace here ?
Thanks
Jianchao
> I guess it's the same issue the IsraelR/Bart/Ming are trying to fix in the
> block layer regarding completing requests.
> I'll add IsraelR proposed fix to nvme-rdma that is currently on hold and see
> what happens.
> Nontheless, I don't like the situation that the reset and delete flows can
> run concurrently.
>
> -Max.
>
> On 4/26/2018 11:27 AM, jianchao.wang wrote:
>> Hi Max
>>
>> I did a similar test on nvme-rdma, the underlying fabric is soft-RoCE.
>> A io loop, reset controller loop and a delete/create controller loop.
>> And found io hang below:
>>
>> [ 230.884590] WARNING: CPU: 0 PID: 150 at
>> /home/will/u04/source_code/linux-stable/drivers/nvme/host/rdma.c:1755
>> nvme_rdma_reset_ctrl_work+0x3d/0xb0 [nvme_rdma]
>> [ 230.884689] CPU: 0 PID: 150 Comm: kworker/u16:3 Not tainted 4.17.0-rc1+
>> #16
>> [ 230.884690] Hardware name: LENOVO 10MLS0E339/3106, BIOS M1AKT22A
>> 06/27/2017
>> [ 230.884693] Workqueue: nvme-reset-wq nvme_rdma_reset_ctrl_work [nvme_rdma]
>> [ 230.884696] RIP: 0010:nvme_rdma_reset_ctrl_work+0x3d/0xb0 [nvme_rdma]
>> [ 230.884697] RSP: 0018:a9e30255be40 EFLAGS: 00010246
>> [ 230.884699] RAX: RBX: 9633b64c2000 RCX:
>>
>> [ 230.884700] RDX: 0001 RSI: RDI:
>> 9ac05516
>> [ 230.884701] RBP: 9633b64c23b8 R08: 0001 R09:
>>
>> [ 230.884702] R10: R11: R12:
>> 9633b64c2970
>> [ 230.884703] R13: R14: 096340ffcc80 R15:
>> 9634102af9c0
>> [ 230.884705] FS: () GS:963422c0()
>> knlGS:
>> [ 230.884706] CS: 0010 DS: ES: CR0: 80050033
>> [ 230.884707] CR2: 01ce9ca4 CR3: 00038040f005 CR4:
>> 003606f0
>> [ 230.884708] DR0: DR1: DR2:
>>
>> [ 230.884709] DR3: DR6: fffe0ff0 DR7:
>> 0400
>> [ 230.884710] Call Trace:
>> [ 230.884717] process_one_work+0x1c0/0x680
>> [ 230.884722] worker_thread+0x22b/0x430
>> [ 230.884728] kthread+0x100/0x140
>> [ 230.884730] ? rescuer_thread+0x370/0x370
>> [ 230.884731] ? kthread_delayed_work_timer_fn+0x80/0x80
>> [ 230.884736] ret_from_fork+0x24/0x30
>> [ 230.884744] Code: ff 48 8d ab b8 03 00 00 48 89 ef e8 1e 25 d7 d9 31 f6
>> 48 89 df e8 44 f9 ff ff be 04 00 00 00 48 89 ef e8 b7 13 d7 d9 84 c0 75 07
>> <0f> 0b 5b 5d 41 5c c3 31 f6 48 89 df e8 b2 fa ff ff 85 c0 75 39
>> [ 230.884799] irq event stamp: 88150
>> [ 230.884802] hardirqs last enabled at (88149): []
>> _raw_spin_unlock_irqrestore+0x59/0x70
>> [ 230.884803] hardirqs last disabled at (88150): []
>> error_entry+0x6c/0xc0
>> [ 230.884805] softirqs last enabled at (87998): []
>> sk_common_release+0x60/0xd0
>> [ 230.884807] softirqs last disabled at (87996): []
>> sk_common_release+0x35/0xd0
>> [ 230.884808] ---[ end trace c03fac253b80d77d ]---
>> [ 277.472094] INFO: task kworker/u16:0:6 blocked for more than 30 seconds.
>> [ 277.473482] Tainted: G W 4.17.0-rc1+ #16
>> [ 277.474825] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
>> this message.
>> [ 277.476293] kworker/u16:0 D 0 6 2 0x8000
>> [ 277.476317] Workqueue: nvme-delete-wq nvme_delete_ctrl_work
>> [ 277.476335] Call Trace:
>> [ 277.476365] ? __schedule+0x3de/0xac0
>> [ 277.476393] schedule+0x3c/0x90
>> [ 277.476405] blk_mq_freeze_queue_wait+0x44/0x90
>> [ 277.476419] ? wait_woken+0x90/0x90
>> [ 277.476437] blk_cleanup_queue+0xe1/0x280
>> [ 277.476453] nvme_ns_remove+0x1c8/0x260
>> [ 277.476475] nvme_remove_namespaces+0x7f/0xa0
>> [ 277.476495] nvme_delete_ctrl_work+0x4b/0x80
>> [ 277.476508] process_one_work+0x1c0/0x680
>> [ 277.476535] worker_thread+0x22b/0x430
>> [ 277.476562] kthread+0x100/0x140
>> [ 277.476572] ? rescuer_thread+0x370/0x370
>> [ 277.476579] ? kthread_delayed_work_timer_fn+0x80/0x80
>> [ 277.476598] ret_from_fork+0x24/0x30
>>
>> ea33345b {.op=READ, .cmd_flags=23, .rq_flags=MQ_INFLIGHT|IO_STAT,
>> .state=idle, .tag=19, .internal_tag=-1}
>> 71218c5a {.op=READ, .cmd_flags=23, .rq_flags=MQ_INFLIGHT|IO_STAT,
>> .state=idle, .tag=45, .internal_tag=-1}
>> root@will-ThinkCentre-M910s:/sys/kernel/debug/block/nvme1c1n1# cat state
>> DYING|BYPASS|NOMERGES|SAME_COMP|NONROT|IO_STAT|DISCARD|NOXMERGES|INIT_DONE|NO_SG_MERGE|POLL|WC|FUA|STATS|QUIESCED
>>
>> This is due to a race following:
>>
>> nvme_delete_ctrl
Re: stable 4.16.5 hmm build error
>What .config is creating this? I have not seen any kbuild reports of this in the past. .config - https://bugzilla.kernel.org/attachment.cgi?id=275579 src - https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.5.tar.xz 2018-04-27 10:30 GMT+03:00 Greg Kroah-Hartman : > On Fri, Apr 27, 2018 at 02:19:24AM +0300, Михаил Носов wrote: >> Oh. Yes. Tag v4.16.5 without commit >> 9d8a463a7016e9e5578a561588a18acef139919c. >> It's in v4.17-rc1/2. >> Thank you. > > That patch does not apply to the stable trees. I'm also confused by the > lack of "real" git commit ids that are being referred to here, that > commit refers to one that is not valid. > >> 2018-04-27 0:52 GMT+03:00 Randy Dunlap : >> >> > https://bugzilla.kernel.org/show_bug.cgi?id=199515 >> > >> > kernel/fork.o: In function `__mmdrop': >> > /kernel/build_kernel/linux-4.16.4/kernel/fork.c:600: undefined reference >> > to `hmm_mm_destroy' > > What .config is creating this? I have not seen any kbuild reports of > this in the past. > >> > >> > "It is also reproduced in linux-4.16.5" >> > >> > >> > There have been a few attempts to fix this build error. The kernel >> > mainline >> > repo seems to have it fixed, but it looks to me like Arnd's latest patch >> > (9d8a463a7016e: "mm/hmm: fix header file if/else/endif maze, again") >> > was mis-merged to 4.16.5 stable. >> > >> > Please take a look. Do you already have a fixup for this? > > thanks, > > greg k-h
[PATCH 0/3] ASoC: Use gpio_is_valid()
Replace the manual validity checks for the GPIO with the gpio_is_valid(). Arvind Yadav (3): [PATCH 1/3] ASoC: tlv320dac33: Use gpio_is_valid() [PATCH 2/3] ASoC: tpa6130a2: Use gpio_is_valid() [PATCH 3/3] ASoC: samsung: Use gpio_is_valid() sound/soc/codecs/tlv320dac33.c | 10 +- sound/soc/codecs/tpa6130a2.c | 8 sound/soc/samsung/s3c24xx_simtec.c | 10 +- 3 files changed, 14 insertions(+), 14 deletions(-) -- 1.9.1
Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers
On Fri, Apr 27, 2018 at 10:29 AM, Sekhar Nori wrote: > On Friday 27 April 2018 01:22 PM, Arnd Bergmann wrote: >> On Fri, Apr 27, 2018 at 4:28 AM, David Lechner wrote: >>> On 04/26/2018 12:31 PM, Rich Felker wrote: >> >> I haven't seen the discussion about your clock drivers, but I know that >> usually only a very small subset of the clocks on an SoC are needed >> that 'early', and you should use a regular platform driver for the rest. > > Its true that the subset is small, but they are either PLL bypass clocks > or clocks derived out of the main clock gate controller on the Soc > (DaVinci PSC). So we need some non-platform-device based initialization > support in the two main clock drivers used on mach-davinci anyway. > >> Can you elaborate on which devices need to access your clocks before >> you are able to initialize the clk driver through the regular platform_driver >> framework? Do any of these need complex interactions with the clk >> subsystem, or do you just need to ensure they are turned on? > > Its just the timer IP. There is no complex interaction, just need to > ensure that the clock is registered with the framework and also switched > on when there is a gate clock. > > The latest attempt by David for this was posted last night here: > > https://lkml.org/lkml/2018/4/26/1093 Ok, so the workaround in that series is to set up the timer clk manually in the SoC specific code (dm365_init_time etc) and register it to the clk subsystem, right? That seems to be a much more appropriate workaround than adding back early_platform devices. We can always try to do something better later, but for now I'm happy with that as a workaround. Please clarify: do we have to set up the clk registers for the timer here just because we can't rely on the bootloader to have it set up initially, or is there some other reason? I think what some other platforms do is to treat the timer clock as a fixed-rate clock that is not managed by the actual clk driver but is set up by uboot before we enter the kernel, and then the clk driver just makes sure it doesn't turn that clk off later. Arnd
[PATCH 3/3] ASoC: samsung: Use gpio_is_valid()
Replace the manual validity checks for the GPIO with the
gpio_is_valid().
Signed-off-by: Arvind Yadav
---
sound/soc/samsung/s3c24xx_simtec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/samsung/s3c24xx_simtec.c
b/sound/soc/samsung/s3c24xx_simtec.c
index 6de63f3..23e8ef9d 100644
--- a/sound/soc/samsung/s3c24xx_simtec.c
+++ b/sound/soc/samsung/s3c24xx_simtec.c
@@ -229,7 +229,7 @@ static int attach_gpio_amp(struct device *dev,
int ret;
/* attach gpio amp gain (if any) */
- if (pdata->amp_gain[0] > 0) {
+ if (gpio_is_valid(pdata->amp_gain[0])) {
ret = gpio_request(pd->amp_gain[0], "gpio-amp-gain0");
if (ret) {
dev_err(dev, "cannot get amp gpio gain0\n");
@@ -248,7 +248,7 @@ static int attach_gpio_amp(struct device *dev,
}
/* note, currently we assume GPA0 isn't valid amp */
- if (pdata->amp_gpio > 0) {
+ if (gpio_is_valid(pdata->amp_gpio)) {
ret = gpio_request(pd->amp_gpio, "gpio-amp");
if (ret) {
dev_err(dev, "cannot get amp gpio %d (%d)\n",
@@ -263,7 +263,7 @@ static int attach_gpio_amp(struct device *dev,
return 0;
err_amp:
- if (pd->amp_gain[0] > 0) {
+ if (gpio_is_valid(pd->amp_gain[0])) {
gpio_free(pd->amp_gain[0]);
gpio_free(pd->amp_gain[1]);
}
@@ -273,12 +273,12 @@ static int attach_gpio_amp(struct device *dev,
static void detach_gpio_amp(struct s3c24xx_audio_simtec_pdata *pd)
{
- if (pd->amp_gain[0] > 0) {
+ if (gpio_is_valid(pd->amp_gain[0])) {
gpio_free(pd->amp_gain[0]);
gpio_free(pd->amp_gain[1]);
}
- if (pd->amp_gpio > 0)
+ if (gpio_is_valid(pd->amp_gpio))
gpio_free(pd->amp_gpio);
}
--
1.9.1
[PATCH 1/3] ASoC: tlv320dac33: Use gpio_is_valid()
Replace the manual validity checks for the GPIO with the
gpio_is_valid().
Signed-off-by: Arvind Yadav
---
sound/soc/codecs/tlv320dac33.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
index a957eae..c23b9db 100644
--- a/sound/soc/codecs/tlv320dac33.c
+++ b/sound/soc/codecs/tlv320dac33.c
@@ -397,13 +397,13 @@ static int dac33_hard_power(struct snd_soc_component
*component, int power)
goto exit;
}
- if (dac33->power_gpio >= 0)
+ if (gpio_is_valid(dac33->power_gpio))
gpio_set_value(dac33->power_gpio, 1);
dac33->chip_power = 1;
} else {
dac33_soft_power(component, 0);
- if (dac33->power_gpio >= 0)
+ if (gpio_is_valid(dac33->power_gpio))
gpio_set_value(dac33->power_gpio, 0);
ret = regulator_bulk_disable(ARRAY_SIZE(dac33->supplies),
@@ -1519,7 +1519,7 @@ static int dac33_i2c_probe(struct i2c_client *client,
dac33->fifo_mode = DAC33_FIFO_BYPASS;
/* Check if the reset GPIO number is valid and request it */
- if (dac33->power_gpio >= 0) {
+ if (gpio_is_valid(dac33->power_gpio)) {
ret = gpio_request(dac33->power_gpio, "tlv320dac33 reset");
if (ret < 0) {
dev_err(&client->dev,
@@ -1548,7 +1548,7 @@ static int dac33_i2c_probe(struct i2c_client *client,
return ret;
err_get:
- if (dac33->power_gpio >= 0)
+ if (gpio_is_valid(dac33->power_gpio))
gpio_free(dac33->power_gpio);
err_gpio:
return ret;
@@ -1561,7 +1561,7 @@ static int dac33_i2c_remove(struct i2c_client *client)
if (unlikely(dac33->chip_power))
dac33_hard_power(dac33->component, 0);
- if (dac33->power_gpio >= 0)
+ if (gpio_is_valid(dac33->power_gpio))
gpio_free(dac33->power_gpio);
return 0;
--
1.9.1
Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers
2018-04-27 9:52 GMT+02:00 Arnd Bergmann : > On Fri, Apr 27, 2018 at 4:28 AM, David Lechner wrote: >> On 04/26/2018 12:31 PM, Rich Felker wrote: >>> >>> On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote: From: Bartosz Golaszewski This is a follow to my series[1] the aim of which was to introduce device tree support for early platform devices. It was received rather negatively. Aside from using device tree to pass implementation specific details to the system, two important concerns were raised: no probe deferral support and the fact that currently the early devices never get converted to actual platform drivers. This series is a proof-of-concept that's trying to address those issues. The only user of the current version of early platform drivers is the SuperH architecture. If this series eventually gets merged, we could simply replace the other solution. >>> >>> >>> Looking at a quick output of: >>> >>> grep -r -A10 early_devices[[] arch/sh/kernel/ >>> >>> it looks like all of the existing early platform devices are serial >>> ports, clocks, and clocksources. The switch to device tree should pick >>> them all up from CLK_OF_DECLARE, TIMER_OF_DECLARE, and >>> EARLYCON_DECLARE. Until that's complete, the existing code works >>> as-is. I don't see what problem you're trying to solve. >> >> >> The problem for us is that clk maintainers don't want new drivers to use >> CLK_OF_DECLARE and instead use platform devices. I have just written such >> a new driver that is shared by 6 different SoCs. For some combinations of >> SoCs and clocks, using a platform device is fine but on others we need to >> register early, so the drivers now have to handle both cases, which is >> kind of messy and fragile. If there is a generic way to register platform >> devices early, then the code is simplified because we only have to handle >> one method of registering the clocks instead of two. > > The early_platform code is certainly not a way to make things simpler, > it just adds one more way of doing the same thing that OF_CLK_DECLARE > already does. We removed the last early_platform users on ARM a few > years ago, and I would hope to leave it like that. > > I haven't seen the discussion about your clock drivers, but I know that > usually only a very small subset of the clocks on an SoC are needed > that 'early', and you should use a regular platform driver for the rest. > > Can you elaborate on which devices need to access your clocks before > you are able to initialize the clk driver through the regular platform_driver > framework? Do any of these need complex interactions with the clk > subsystem, or do you just need to ensure they are turned on? > > Arnd The problem I'm trying to solve is the following: We have platforms out there which still use both board files and device tree. They are still comercially supported and are not going anywhere anytime soon. Some of these platforms are being actively maintained and cleaned-up. An example is the DaVinci platform: David has recently converted all the SoCs and boards to using the common clock framework. I'm cleaning up some other parts too. The problem with the legacy board code is that a lot of things that should be platform drivers ended up in arch/arm/mach-*. We're now slowly moving this code to drivers/ but some initialization code (timers, critical clocks, irqs) needs to be called early in the boot sequence. When you're saying that we already have all the OF_DECLARE macros, it seems to me that you're forgetting that we also want to keep supporting the board files. So without the early platform drivers we need to use a mix of OF_DECLARE and handcrafted initialization in arch/arm/mach-* since we can't call platform_device_register() that early. This blocks us from completely moving the should-be-driver code to drivers/, because these drivers *need* to support both cases. The main problem with OF_DECLARE is that although we have corresponding device nodes, we never actually register any real linux devices. If we add to this the fact that current early platform drivers implementation is broken (for reasons I mentioned in the cover letter) the support gets really messy, since we can have up to three entry points to the driver's code. Other issues come to mind as well: if we're using OF_DECLARE we can't benefit from devm* routines. My aim is to provide a clean, robust and generic way of probing certain devices early and then converting them to actual platform devices when we're advanced enough into the boot sequence. If we merged such a framework, we could work towards removing both the previous early platform devices (in favor of the new mechanism) and maybe even deprecating and replacing OF_DECLARE(), since we could simply early probe the DT drivers. Personally I see OF_DECLARE as a bigger hack than early devices. My patch tries to address exa
[PATCH 2/3] ASoC: tpa6130a2: Use gpio_is_valid()
Replace the manual validity checks for the GPIO with the
gpio_is_valid().
Signed-off-by: Arvind Yadav
---
sound/soc/codecs/tpa6130a2.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 616cd4b..18f32b9 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -62,7 +62,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool
enable)
return ret;
}
/* Power on */
- if (data->power_gpio >= 0)
+ if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 1);
/* Sync registers */
@@ -72,7 +72,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool
enable)
dev_err(data->dev,
"Failed to sync registers: %d\n", ret);
regcache_cache_only(data->regmap, true);
- if (data->power_gpio >= 0)
+ if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 0);
ret2 = regulator_disable(data->supply);
if (ret2 != 0)
@@ -89,7 +89,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool
enable)
regcache_cache_only(data->regmap, true);
/* Power off */
- if (data->power_gpio >= 0)
+ if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 0);
ret = regulator_disable(data->supply);
@@ -259,7 +259,7 @@ static int tpa6130a2_probe(struct i2c_client *client,
data->id = id->driver_data;
- if (data->power_gpio >= 0) {
+ if (gpio_is_valid(data->power_gpio)) {
ret = devm_gpio_request(dev, data->power_gpio,
"tpa6130a2 enable");
if (ret < 0) {
--
1.9.1
Re: [PATCHv3 3/3] tools bpftool: Display license GPL compatible in prog show/list
On Thu, Apr 26, 2018 at 10:49:25PM +0200, Daniel Borkmann wrote:
> On 04/26/2018 10:18 AM, Jiri Olsa wrote:
> [...]
> > v3 of the last patch attached, the branch is also updated
> >
> > thanks,
> > jirka
> >
> >
> > ---
> > Display the license "gpl" string in bpftool prog command, like:
> >
> > # bpftool prog list
> > 5: tracepoint name func tag 57cd311f2e27366b gpl
> > loaded_at Apr 26/09:37 uid 0
> > xlated 16B not jited memlock 4096B
> >
> > # bpftool --json --pretty prog show
> > [{
> > "id": 5,
> > "type": "tracepoint",
> > "name": "func",
> > "tag": "57cd311f2e27366b",
> > "gpl_compatible": true,
> > "loaded_at": "Apr 26/09:37",
> > "uid": 0,
> > "bytes_xlated": 16,
> > "jited": false,
> > "bytes_memlock": 4096
> > }
> > ]
> >
> > Signed-off-by: Jiri Olsa
>
> Ok, v2 from prior two patches and v3 of this one applied to bpf-next. Please
> next time always submit a fresh new series at once, thanks Jiri.
noted, thanks a lot
jirka
Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers
2018-04-27 10:55 GMT+02:00 Arnd Bergmann : > On Fri, Apr 27, 2018 at 10:29 AM, Sekhar Nori wrote: >> On Friday 27 April 2018 01:22 PM, Arnd Bergmann wrote: >>> On Fri, Apr 27, 2018 at 4:28 AM, David Lechner wrote: On 04/26/2018 12:31 PM, Rich Felker wrote: > >>> >>> I haven't seen the discussion about your clock drivers, but I know that >>> usually only a very small subset of the clocks on an SoC are needed >>> that 'early', and you should use a regular platform driver for the rest. >> >> Its true that the subset is small, but they are either PLL bypass clocks >> or clocks derived out of the main clock gate controller on the Soc >> (DaVinci PSC). So we need some non-platform-device based initialization >> support in the two main clock drivers used on mach-davinci anyway. >> >>> Can you elaborate on which devices need to access your clocks before >>> you are able to initialize the clk driver through the regular >>> platform_driver >>> framework? Do any of these need complex interactions with the clk >>> subsystem, or do you just need to ensure they are turned on? >> >> Its just the timer IP. There is no complex interaction, just need to >> ensure that the clock is registered with the framework and also switched >> on when there is a gate clock. >> >> The latest attempt by David for this was posted last night here: >> >> https://lkml.org/lkml/2018/4/26/1093 > > Ok, so the workaround in that series is to set up the timer clk manually > in the SoC specific code (dm365_init_time etc) and register it to the > clk subsystem, right? > > That seems to be a much more appropriate workaround than adding > back early_platform devices. We can always try to do something better > later, but for now I'm happy with that as a workaround. > Just to clarify: this is not bringing back the hacky early platform devices from before. It's a new approach that actually uses the linux platform driver model (unlike the current mechanism which only uses the same data structures). Thanks, Bart
[PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being compatible with old
kexec-tools).
- If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
- If fails, try to reserve X from MAXMEM top down.
It's more transparent and user-friendly.
If crashkernel is large and the reserved is beyond 896M, old kexec-tools
is not compatible with new kernel because old kexec-tools can not load
kernel at high memory region, there was an old discussion below:
https://lkml.org/lkml/2013/10/15/601
But actually the behavior is consistent during my test. Suppose
old kernel fail to reserve memory at low areas, kdump does not
work because no meory reserved. With this patch, suppose new kernel
successfully reserved memory at high areas, old kexec-tools still fail
to load kdump kernel (tested 2.0.2), so it is acceptable, no need to
worry about the compatibility.
Signed-off-by: Dave Young
---
arch/x86/kernel/setup.c | 16
1 file changed, 16 insertions(+)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -545,6 +545,22 @@ static void __init reserve_crashkernel(v
high ? CRASH_ADDR_HIGH_MAX
: CRASH_ADDR_LOW_MAX,
crash_size, CRASH_ALIGN);
+#ifdef CONFIG_X86_64
+ /*
+* crashkernel=X reserve below 896M fails? Try below 4G
+*/
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ (1ULL << 32),
+ crash_size, CRASH_ALIGN);
+ /*
+* crashkernel=X reserve below 4G fails? Try MAXMEM
+*/
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(CRASH_ALIGN,
+ CRASH_ADDR_HIGH_MAX,
+ crash_size, CRASH_ALIGN);
+#endif
if (!crash_base) {
pr_info("crashkernel reservation failed - No suitable
area found.\n");
return;
[PATCH 2/2] kdump: round up the total memory size to 128M for crashkernel reservation
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
Legacy boot kvm guest: 0x7ff7cc00
This is also a problem on arm64 UEFI booted system according to my test.
Thus for example crashkernel=1G-2G:128M, if we have a 1G memory
machine, we get total size 1023M from firmware then it will not fall
into 1G-2G thus no memory reserved. User will never know that, it is
hard to let user to know the exact total value we get in kernel
An option is to use dmi/smbios to get physical memory size, but it's not
reliable as well. According to Prarit hardware vendors sometimes screw this up.
Thus round up total size to 128M to workaround this problem.
Signed-off-by: Dave Young
---
kernel/crash_core.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
--- linux-x86.orig/kernel/crash_core.c
+++ linux-x86/kernel/crash_core.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -41,6 +42,15 @@ static int __init parse_crashkernel_mem(
unsigned long long *crash_base)
{
char *cur = cmdline, *tmp;
+ unsigned long long total_mem = system_ram;
+
+ /*
+* Firmware sometimes reserves some memory regions for it's own use.
+* so we get less than actual system memory size.
+* Workaround this by round up the total size to 128M which is
+* enough for most test cases.
+*/
+ total_mem = roundup(total_mem, SZ_128M);
/* for each entry of the comma-separated list */
do {
@@ -85,13 +95,13 @@ static int __init parse_crashkernel_mem(
return -EINVAL;
}
cur = tmp;
- if (size >= system_ram) {
+ if (size >= total_mem) {
pr_warn("crashkernel: invalid size\n");
return -EINVAL;
}
/* match ? */
- if (system_ram >= start && system_ram < end) {
+ if (total_mem >= start && total_mem < end) {
*crash_size = size;
break;
}
Re: [RFC v3 0/5] virtio: support packed ring
On Fri, Apr 27, 2018 at 02:17:51PM +0800, Jason Wang wrote:
> On 2018年04月27日 12:18, Michael S. Tsirkin wrote:
> > On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote:
> > > On 2018年04月25日 13:15, Tiwei Bie wrote:
> > > > Hello everyone,
> > > >
> > > > This RFC implements packed ring support in virtio driver.
> > > >
> > > > Some simple functional tests have been done with Jason's
> > > > packed ring implementation in vhost:
> > > >
> > > > https://lkml.org/lkml/2018/4/23/12
> > > >
> > > > Both of ping and netperf worked as expected (with EVENT_IDX
> > > > disabled). But there are below known issues:
> > > >
> > > > 1. Reloading the guest driver will break the Tx/Rx;
> > > Will have a look at this issue.
> > >
> > > > 2. Zeroing the flags when detaching a used desc will
> > > > break the guest -> host path.
> > > I still think zeroing flags is unnecessary or even a bug. At host, I track
> > > last observed avail wrap counter and detect avail like (what is suggested
> > > in
> > > the example code in the spec):
> > >
> > > static bool desc_is_avail(struct vhost_virtqueue *vq, __virtio16 flags)
> > > {
> > > bool avail = flags & cpu_to_vhost16(vq, DESC_AVAIL);
> > >
> > > return avail == vq->avail_wrap_counter;
> > > }
> > >
> > > So zeroing wrap can not work with this obviously.
> > >
> > > Thanks
> > I agree. I think what one should do is flip the available bit.
> >
>
> But is this flipping a must?
>
> Thanks
Yeah, that's my question too. It seems to be a requirement
for driver that, the only change to the desc status that a
driver can do during running is to mark the desc as avail,
and any other changes to the desc status are not allowed.
Similarly, the device can only mark the desc as used, and
any other changes to the desc status are also not allowed.
So the question is, are there such requirements?
Based on below contents in the spec:
"""
Thus VIRTQ_DESC_F_AVAIL and VIRTQ_DESC_F_USED bits are different
for an available descriptor and equal for a used descriptor.
Note that this observation is mostly useful for sanity-checking
as these are necessary but not sufficient conditions
"""
It seems that, it's necessary for devices to check whether
the AVAIL bit and USED bit are different.
Best regards,
Tiwei Bie
Re: [REGRESSION][BISECTED] i.MX6 pinctrl hogs stopped working
On 17/04/18 09:50, Richard Fitzgerald wrote: On 10/04/18 19:33, Mika Penttilä wrote: On 10.04.2018 13:21, Richard Fitzgerald wrote: On 04/04/18 06:33, Mika Penttilä wrote: Hi! Reverting this made the hogs on a i.MX6 board work again. : commit b89405b6102fcc3746f43697b826028caa94c823 Author: Richard Fitzgerald Date: Wed Feb 28 15:53:06 2018 + pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs --Mika I think you should check whether the bug is with the i.MX6 driver relying on the previous buggy behaviour of pinctrl. I haven't got i.MX6 hardware to test myself. The bug I fixed in that patch was that when pinctrl is probing a pinctrl driver it would try to apply all the pinctrl settings listed in a dt node to the pinctrl driver it is probing instead of the pinctrl drivers they actually refer to. This was a bug introduced by an earlier patch (which unfortunately I forgot to include a fixes line reference to) pinctrl: core: Use delayed work for hogs So if a pinctrl driver "A" had a dependency on another pinctrl driver "B" those dependencies wouldn't be properly created because all the "B" pinctrl DT entries would be attempted against "A" instead of "B". This caused failures if a pinctrl driver had a dependency on another pinctrl driver, of if creating a pinctrl driver that is a child of an MFD and that MFD has dependencies on another pinctrl driver. Hard to say, but the kernel/dts has worked ok for 3+ years, from 3.17 until 4.17-rc. Nothing fancy, just normal hogs, in two groups. Can send you relevant pieces of DT if interested. --Mika Tell me where in the kernel tree the the dts files and the source for the pinctrl driver that uses them and which dts node, and I will look at what the driver is doing. Hi, Sorry, I have been very busy and haven't had time to look at the i.MX6 driver yet.
Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM
Hi, This is a resend of below patches: http://lists.infradead.org/pipermail/kexec/2017-October/019569.html I dropped the original patch 1 since Baoquan is not happy with it. For patch 2 (the 1st patch in this series), there is some improvement comment from Baoquan to create some generic memblock iteration function. But nobody has time to work on it for the time being. According to offline discussion with him. That can be done in the future if someone is interested. We can go with the current kdump only fixes. Other than above, the patches are just same. Thanks Dave
Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
On Fri, 2018-04-27 at 07:25 +0200, Marcel Holtmann wrote: > Hi Sean, > > > This adds a driver for the MediaTek serial protocol based on H4 > > protocol, > > which can enable the built-in Bluetooth device inside MT7622 SoC. > > > > Signed-off-by: Sean Wang > > --- > > [... snip ...] > > > > where could I find the newest btuart.c (which seems cannot be found in > > 4.17 rc2)? It seems a time to rewrite the driver based on btuart.c > > It is not merged yet. I posted RFC patches to the mailing list. > got it. > > > > the Bluetooth device can't survive in a power/down cycle and > > > > * power on should be including > > - enable clk and power domain > > - download firmware through specific ACL command > > - send specific commands to configure bluetooth (Required to note that > > the steps should be after downloading firmware because the behavior for > > the command might be changed by the firmware) > > Then this sounds like you need a quirk that runs setup() after every open() > and not just after the first open(). You would be the first hardware that > looses their firmware, but that is fine, I almost expect that at some point > someone comes along and requires this. So just create a new > HCI_QUIRK_NON_PERSISTENT_SETUP. > Yes, it should be good to have an option HCI_QUIRK_NON_PERSISTENT_SETUP to allow us to run setup() for every open(). When users are feeling unexpected thing happening on its device, they always have a habit trying to restart device from UI. If close() -> open() can completely power reset a bluetooth device and then it can recover from any fatal error to the initial state as at boot. It's good for these problems specially hard to be reproduced and required to reboot the whole machine to save. However, it would take a little longer time on open() since it takes extra time to make firmware download and reconfiguration. > > * power off should be including > > - send specific commands, such as to disable bluetooth > > So try to put these in shutdown() > got it. > > - disable power domain and clk > > And do this in close(). > got it. > > > >>> > > + > > + return err; [ ... snip ] > .open = mtk_open, > >> > > Go with a brand new btmtkuart.c driver. I really sounds you don’t want the > hci_ldisc.c framework in your way. You want direct control over the core > callbacks. > 1) In fact. the device is working via a internal serial bus, rather than via uart for mt7622. so could i call it btmtkserial.c ? Becasue mediatek indeed also have bluetooth over uart, if i called it btmtkserialc, the same code logic I think can be fit to all other devices using either uart or internal serial bus. 2) Yes, i don't want hci_ldisc. so far i thought serdev version is enough, and i preferred that bluetotoh device don't depend on any utility on user space to launch. 3) last question if i have bluetooth over usb, the usb version bluetooth can reuse btmtkserial.c code? > Regards > > Marcel >
Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent
On 04/27/2018 10:27 AM, Greg KH wrote:
> On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote:
>> Currently function debugfs_create_dir() creates a new
>> directory in the debugfs (usually mounted /sys/kernel/debug)
>> with permission rwxr-xr-x. This is hard coded.
>>
>> Change this to use the parent directory permission.
>>
>> Fixes: edac65eaf8d5c ("debugfs: take mode-dependent parts of
>> debugfs_get_inode() into callers")
>> Signed-off-by: Thomas Richter
>> Cc: Greg Kroah-Hartman
>> ---
>> fs/debugfs/inode.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
>> index 13b01351dd1c..80618330d86a 100644
>> --- a/fs/debugfs/inode.c
>> +++ b/fs/debugfs/inode.c
>> @@ -512,7 +512,10 @@ struct dentry *debugfs_create_dir(const char *name,
>> struct dentry *parent)
>> if (unlikely(!inode))
>> return failed_creating(dentry);
>>
>> -inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
>> +if(!parent)
>> +parent = debugfs_mount->mnt_root;
>> +inode->i_mode = S_IFDIR | (d_inode(parent)->i_mode
>> + & (S_IRWXU | S_IRWXG));
>> inode->i_op = &simple_dir_inode_operations;
>> inode->i_fop = &simple_dir_operations;
>>
>
> This looks ok, but is it going to change the permissions of existing
> stuff in ways that might breaks things, right?
Right, but debugfs is usually mounted on /sys/kernel/debug with
permissions rwx to root owner. It can be changed after the mount, of course.
Unless this is done, the directory permissions for /sys/kernel/debug
will stop any descend regardless of the subdirectory permissions.
>
> Have you done a before/after comparison?
I have tested this patch on my Linux 4.17.0rc2 kernel on s390.
That worked well, I have not tested other systems.
--
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294
Re: [PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat
On 04/26/2018 11:55 PM, David Rientjes wrote: > On Thu, 26 Apr 2018, Michal Hocko wrote: > >>> Don't show nr_indirectly_reclaimable in /proc/vmstat, >>> because there is no need in exporting this vm counter >>> to the userspace, and some changes are expected >>> in reclaimable object accounting, which can alter >>> this counter. >>> >>> Signed-off-by: Roman Gushchin >>> Cc: Vlastimil Babka >>> Cc: Matthew Wilcox >>> Cc: Andrew Morton >>> Cc: Alexander Viro >>> Cc: Michal Hocko >>> Cc: Johannes Weiner >> >> This is quite a hack. I would much rather revert the counter and fixed >> it the way Vlastimil has proposed. But if there is a strong opposition >> to the revert then this is probably the simples thing to do. Therefore >> > > Implementing this counter as a vmstat doesn't make much sense based on how > it's used. Do you have a link to what Vlastimil proposed? I haven't seen > mention of alternative ideas. It was in the original thread, see e.g. <08524819-14ef-81d0-fa90-d7af13c6b...@suse.cz> However it will take some time to get that in mainline, and meanwhile the current implementation does prevent a DOS. So I doubt it can be fully reverted - as a compromise I just didn't want the counter to become ABI. TBH though, other people at LSF/MM didn't seem concerned that /proc/vmstat is an ABI that we can't change (i.e. counters have been presumably removed in the past already).
Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h6: add device tree nodes for MMC controllers
Hi,
On 27/04/18 09:36, Icenowy Zheng wrote:
>
>
> 于 2018年4月27日 GMT+08:00 上午12:45:38, Andre Przywara 写到:
>> Hi,
>>
>> On 26/04/18 15:07, Icenowy Zheng wrote:
>>> The Allwinner H6 SoC have 3 MMC controllers.
>>>
>>> Add device tree nodes for them.
>>>
>>> Signed-off-by: Icenowy Zheng
>>> ---
>>> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56
>>
>>> 1 file changed, 56 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>>> index 4debc3962830..3cbfc035c979 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>>> @@ -124,12 +124,68 @@
>>> interrupt-controller;
>>> #interrupt-cells = <3>;
>>>
>>> + mmc0_pins: mmc0-pins {
>>> + pins = "PF0", "PF1", "PF2", "PF3",
>>> + "PF4", "PF5";
>>> + function = "mmc0";
>>> + drive-strength = <30>;
>>> + bias-pull-up;
>>> + };
>>> +
>>> + mmc2_pins: mmc2-pins {
>>> + pins = "PC1", "PC4", "PC5", "PC6",
>>> + "PC7", "PC8", "PC9", "PC10",
>>> + "PC11", "PC12", "PC13", "PC14";
>>> + function = "mmc2";
>>> + drive-strength = <30>;
>>> + bias-pull-up;
>>> + };
>>> +
>>> uart0_ph_pins: uart0-ph {
>>> pins = "PH0", "PH1";
>>> function = "uart0";
>>> };
>>> };
>>>
>>> + mmc0: mmc@402 {
>>> + compatible = "allwinner,sun50i-h6-mmc";
>>
>> This should be:
>> compatible = "allwinner,sun50i-h6-mmc",
>> "allwinner,sun50i-a64-mmc";
>
> I'm intended to not add A64 compatible, as
> H6 is a quite new design
> (new process) and there might be different behavior, even on mmc0/1.
But as your patch proves, it is fully backwards compatible: An A64
driver works with this device.
And this is what this compatible string list says: If your system does
not have a specific H6 driver, you can use an A64 driver.
You might not get all the (potentially) new features, but it covers
everything the A64 has.
And a new silicon process doesn't matter here, since the software
interface is unchanged. *If* we find bugs, we can add quirks matching on
the H6 compatible string - that's why we put it here already, despite
having a matching string in the kernel at the moment.
>>> + reg = <0x0402 0x1000>;
>>> + clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
>>> + clock-names = "ahb", "mmc";
>>> + resets = <&ccu RST_BUS_MMC0>;
>>> + reset-names = "ahb";
>>> + interrupts = ;
>>> + status = "disabled";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + };
>>> +
>>> + mmc1: mmc@4021000 {
>>> + compatible = "allwinner,sun50i-h6-mmc";
>>
>> same here
>>
>>> + reg = <0x04021000 0x1000>;
>>> + clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
>>> + clock-names = "ahb", "mmc";
>>> + resets = <&ccu RST_BUS_MMC1>;
>>> + reset-names = "ahb";
>>> + interrupts = ;
>>> + status = "disabled";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + };
>>> +
>>> + mmc2: mmc@4022000 {
>>> + compatible = "allwinner,sun50i-h6-emmc";
>>
>> and here:
>> compatible = "allwinner,sun50i-h6-emmc",
>> "allwinner,sun50i-a64-emmc";
>
> MMC2 on H6 has EMCE capability, so surely there should
> only be H6 compatible, and no A64 one.
Same as above, the A64 eMMC is a subset of the H6 eMMC, so the A64 eMMC
driver can drive the H6 as well. And again your code proves that,
because it behaves exactly the same as for the A64.
In case we ever get support for the EMCE, we add the new compatible
string to the driver and tie it to the new feature. So newer kernels can
use this feature, older kernel will just not, but can happily use the
eMMC anyway.
Cheers,
Andre.
Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices
On 26/04/2018 15:23, John Garry wrote:
+
On 26/04/2018 15:08, Mika Westerberg wrote:
On Thu, Apr 26, 2018 at 02:49:49PM +0100, John Garry wrote:
diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
index 2d4611e..b04425b 100644
--- a/drivers/bus/hisi_lpc.c
+++ b/drivers/bus/hisi_lpc.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include "../tty/serial/8250/8250.h"
#define DRV_NAME "hisi-lpc"
@@ -345,6 +347,7 @@ static void hisi_lpc_comm_outs(void *hostdata,
unsigned
long pio,
#define MFD_CHILD_NAME_LEN (ACPI_ID_LEN +
sizeof(MFD_CHILD_NAME_PREFIX) -
1)
struct hisi_lpc_mfd_cell {
+struct plat_serial8250_port serial8250_port;
struct mfd_cell_acpi_match acpi_match;
char name[MFD_CHILD_NAME_LEN];
char pnpid[ACPI_ID_LEN];
@@ -513,10 +516,31 @@ static int hisi_lpc_acpi_probe(struct device
*hostdev)
dev_warn(&child->dev, "set resource fail (%d)\n", ret);
return ret;
}
+if (!strcmp(acpi_device_hid(child), "HISI1031")) {
Hi Mika,
Hmm, there is a way in struct mfd_cell to match child devices using _HID
so is there something preventing you from using that?
Not that I know about. Can you describe this method? I guess I also
don't need to set the mfd_cell pnpid either for this special case device.
So we using the mfd_cell to match child devices using _HID. At a glance,
I don't actually see other drivers to use mfd_cell_acpi_match.pnpid .
Anyway we don't use static tables as we need to update the resources of
the cell dynamically. However I do look at a driver like
intel_quark_i2c_gpio.c, and this dynamically modifies the value of
global mfd_cell array here:
https://elixir.bootlin.com/linux/latest/source/drivers/mfd/intel_quark_i2c_gpio.c#L266
I know the cell array is only used at probe time, but this did not look
to be good standard practice to me.
Thanks,
John
Thanks,
John
.
Re: [PATCH v7 0/7] clk: meson-axg: Add AO Cloclk and Reset driver
On Thu, 2018-04-26 at 16:44 +0800, Yixun Lan wrote: > This patch try to add AO clock and Reset driver for Amlogic's > Meson-AXG SoC. > Please note that patch 7 need to wait for the DTS changes[3] merged > into mainline first, otherwise it will break the serial console. > > patch 2: factor the common code into a dedicated file > patch 3-5: add the aoclk driver for AXG SoC > patch 6-7: drop unnecessary clock flags > > changes since v6 at [7]: > - fix over 80 chars chechpatch error > - add Philip's Ack on patch 5 > - drop extra end of newline > > changes since v5 at [6]: > - drop unnecessary header files > - add 'axg_aoclk' prefix to clk driver, make them more consistent > - add missing end new line.. > > changes since v4 at [5]: > - fix return err > - introduce CONFIG_COMMON_CLK_MESON_AO > - format/style minor fix > > changes since v3 at [4]: > - add 'const' contraint to the read-only data > - switch to devm_of_clk_add_hw_provider API > - check return value of devm_reset_controller_register > > changes since v2 at [2]: > - rework meson_aoclkc_probe() which leverage the of_match_data > - merge patch 5-6 into this series > - seperate DTS patch, will send to Kevin Hilman independently > > changes since v1 at [0]: > - rebase to clk-meson's branch 'next/drivers' [1] > - fix license, update to BSD-3-Clause > - drop un-used include header file > > [0] https://lkml.kernel.org/r/20180209070026.193879-1-yixun@amlogic.com > [1] git://github.com/BayLibre/clk-meson.git branch: next-drivers > [2] https://lkml.kernel.org/r/20180323143816.200573-1-yixun@amlogic.com > [3] https://lkml.kernel.org/r/20180326081809.49493-4-yixun@amlogic.com > [4] https://lkml.kernel.org/r/20180328025050.221585-1-yixun@amlogic.com > [5] https://lkml.kernel.org/r/20180408031938.153474-1-yixun@amlogic.com > [6] https://lkml.kernel.org/r/20180409143749.71197-1-yixun@amlogic.com > [7] https://lkml.kernel.org/r/20180419135426.155794-1-yixun@amlogic.com Yixun, Your series looks mostly Ok to me, apart from the problem reported by Philipp. However, once applied, if the clkc ao controller is enabled, both gxl and axg fail to complete the boot. Could you please explain how this was tested ?? Not merging it until we get to the bottom of this. > > > Qiufang Dai (1): > clk: meson-axg: Add AO Clock and Reset controller driver > > Yixun Lan (6): > clk: meson: migrate to devm_of_clk_add_hw_provider API > clk: meson: aoclk: refactor common code into dedicated file > dt-bindings: clock: axg-aoclkc: New binding for Meson-AXG SoC > dt-bindings: clock: reset: Add AXG AO Clock and Reset Bindings > clk: meson: drop CLK_SET_RATE_PARENT flag > clk: meson: drop CLK_IGNORE_UNUSED flag > > .../bindings/clock/amlogic,gxbb-aoclkc.txt| 1 + > drivers/clk/meson/Kconfig | 8 + > drivers/clk/meson/Makefile| 3 +- > drivers/clk/meson/axg-aoclk.c | 163 ++ > drivers/clk/meson/axg-aoclk.h | 29 > drivers/clk/meson/gxbb-aoclk.c| 95 -- > drivers/clk/meson/gxbb-aoclk.h| 5 + > drivers/clk/meson/meson-aoclk.c | 81 + > drivers/clk/meson/meson-aoclk.h | 34 > include/dt-bindings/clock/axg-aoclkc.h| 26 +++ > include/dt-bindings/reset/axg-aoclkc.h| 20 +++ > 11 files changed, 401 insertions(+), 64 deletions(-) > create mode 100644 drivers/clk/meson/axg-aoclk.c > create mode 100644 drivers/clk/meson/axg-aoclk.h > create mode 100644 drivers/clk/meson/meson-aoclk.c > create mode 100644 drivers/clk/meson/meson-aoclk.h > create mode 100644 include/dt-bindings/clock/axg-aoclkc.h > create mode 100644 include/dt-bindings/reset/axg-aoclkc.h >
Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake
On Wed, 25 Apr 2018, Ian W MORRISON wrote:
> Can I ask if this is on anyone's radar as I'm concerned this patch will
> stall otherwise?
Pushed to drm-intel-next-queued, thanks for the patch.
I opted to drop the Cc: stable for now. This doesn't mean it can't be
backported later on, I'm just punting on that call right now to make
some forward progress here.
Joonas, please do pick f6d3e06f0747 ("drm/i915/glk: Add MODULE_FIRMWARE
for Geminilake") to drm-intel-fixes to queue it to v4.17.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
Re: [PATCH] reset: uniphier: add LD11/LD20 stream demux system reset control
On Fri, 2018-04-27 at 12:13 +0900, Masahiro Yamada wrote: > 2018-04-27 9:41 GMT+09:00 Katsuhiro Suzuki : > > Add reset lines for MPEG2 transport stream I/O and demux system (HSC) > > on UniPhier LD11/LD20 SoCs. > > > > Signed-off-by: Katsuhiro Suzuki > Acked-by: Masahiro Yamada Thank you, applied to reset/next. regards Philipp
Re: [linux-sunxi] [PATCH 1/3] mmc: sunxi: add support for the MMC controller on H6
Hi,
On 27/04/18 09:38, Icenowy Zheng wrote:
>
>
> 于 2018年4月27日 GMT+08:00 上午12:45:24, Andre Przywara 写到:
>> Hi,
>>
>> On 26/04/18 15:07, Icenowy Zheng wrote:
>>> The new Allwinner H6 SoC have 3 MMC controllers. The first and second
>>> ones are similar to the ones on A64, but the third one adds EMCE
>>> (Embedded Crypto Engine) support which does hardware transparent
>> crypto
>>> on the eMMC.
>>>
>>> As we still do not have support for EMCE, and the support of it is
>>> disabled by defualt, we just duplicate the A64 mmc configurations and
>>> change the compatible string.
>>
>> So if the A64 MMC part is compatible, we should express it like this:
>>
>>> Signed-off-by: Icenowy Zheng
>>> ---
>>> Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 2 ++
>>> drivers/mmc/host/sunxi-mmc.c| 16
>>
>>> 2 files changed, 18 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>> b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>>> index 132e0007d7d6..e6aa5c7a5e12 100644
>>> --- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>>> @@ -16,6 +16,8 @@ Required properties:
>>> * "allwinner,sun9i-a80-mmc"
>>> * "allwinner,sun50i-a64-emmc"
>>> * "allwinner,sun50i-a64-mmc"
>>> + * "allwinner,sun50i-h6-emmc"
>>> + * "allwinner,sun50i-h6-mmc"
>>
>> This should be changed to:
>>
>> * "allwinner,sun50i-h6-emmc", "allwinner,sun50i-a64-emmc"
>> * "allwinner,sun50i-h6-mmc", "allwinner,sun50i-a64-mmc"
>
> This list shouldn't list pairs,
It should, as this is what Rob suggested the other day:
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/564752.html
Cheers,
Andre.
> and as I said in the reply,
> these pairs are not valid.
>
>>
>>> - reg : mmc controller base registers
>>> - clocks : a list with 4 phandle + clock specifier pairs
>>> - clock-names : must contain "ahb", "mmc", "output" and "sample"
>>> diff --git a/drivers/mmc/host/sunxi-mmc.c
>> b/drivers/mmc/host/sunxi-mmc.c
>>> index 97c6b79b7d6f..05e2b5fd7aa4 100644
>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>> @@ -1168,6 +1168,20 @@ static const struct sunxi_mmc_cfg
>> sun50i_a64_emmc_cfg = {
>>> .can_calibrate = true,
>>> };
>>>
>>> +static const struct sunxi_mmc_cfg sun50i_h6_cfg = {
>>> + .idma_des_size_bits = 16,
>>> + .clk_delays = NULL,
>>> + .can_calibrate = true,
>>> + .mask_data0 = true,
>>> + .needs_new_timings = true,
>>> +};
>>> +
>>> +static const struct sunxi_mmc_cfg sun50i_h6_emmc_cfg = {
>>> + .idma_des_size_bits = 13,
>>> + .clk_delays = NULL,
>>> + .can_calibrate = true,
>>> +};
>>> +
>>
>> ... and then we don't need those changes ...
>>
>>> static const struct of_device_id sunxi_mmc_of_match[] = {
>>> { .compatible = "allwinner,sun4i-a10-mmc", .data = &sun4i_a10_cfg
>> },
>>> { .compatible = "allwinner,sun5i-a13-mmc", .data = &sun5i_a13_cfg
>> },
>>> @@ -1176,6 +1190,8 @@ static const struct of_device_id
>> sunxi_mmc_of_match[] = {
>>> { .compatible = "allwinner,sun9i-a80-mmc", .data = &sun9i_a80_cfg
>> },
>>> { .compatible = "allwinner,sun50i-a64-mmc", .data = &sun50i_a64_cfg
>> },
>>> { .compatible = "allwinner,sun50i-a64-emmc", .data =
>> &sun50i_a64_emmc_cfg },
>>> + { .compatible = "allwinner,sun50i-h6-mmc", .data = &sun50i_h6_cfg
>> },
>>> + { .compatible = "allwinner,sun50i-h6-emmc", .data =
>> &sun50i_h6_emmc_cfg },
>>
>> ... and those, at least yet.
>> Should we ever extend the driver to support the EMCE, we can add them
>> at
>> this occasion.
>>
>> So this patch would just add the compatible pairs to the binding doc.
>>
>> Cheers,
>> Andre.
>>
>>> { /* sentinel */ }
>>> };
>>> MODULE_DEVICE_TABLE(of, sunxi_mmc_of_match);
>>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h6: add device tree nodes for MMC controllers
于 2018年4月27日 GMT+08:00 下午5:18:23, Andre Przywara 写到:
>Hi,
>
>On 27/04/18 09:36, Icenowy Zheng wrote:
>>
>>
>> 于 2018年4月27日 GMT+08:00 上午12:45:38, Andre Przywara
> 写到:
>>> Hi,
>>>
>>> On 26/04/18 15:07, Icenowy Zheng wrote:
The Allwinner H6 SoC have 3 MMC controllers.
Add device tree nodes for them.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56
>>>
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>>> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 4debc3962830..3cbfc035c979 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -124,12 +124,68 @@
interrupt-controller;
#interrupt-cells = <3>;
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2", "PF3",
+ "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc2_pins: mmc2-pins {
+ pins = "PC1", "PC4", "PC5", "PC6",
+ "PC7", "PC8", "PC9", "PC10",
+ "PC11", "PC12", "PC13", "PC14";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
uart0_ph_pins: uart0-ph {
pins = "PH0", "PH1";
function = "uart0";
};
};
+ mmc0: mmc@402 {
+ compatible = "allwinner,sun50i-h6-mmc";
>>>
>>> This should be:
>>> compatible = "allwinner,sun50i-h6-mmc",
>>> "allwinner,sun50i-a64-mmc";
>>
>> I'm intended to not add A64 compatible, as
>> H6 is a quite new design
>> (new process) and there might be different behavior, even on mmc0/1.
>
>But as your patch proves, it is fully backwards compatible: An A64
>driver works with this device.
No, my patch only proves "the current A64 driver works
with this device", not "Any A64 driver works with device", as
the current driver doesn't fully use the capability provided
by A64 MMC cobtrollers.
>And this is what this compatible string list says: If your system does
>not have a specific H6 driver, you can use an A64 driver.
>You might not get all the (potentially) new features, but it covers
>everything the A64 has.
>
>And a new silicon process doesn't matter here, since the software
>interface is unchanged. *If* we find bugs, we can add quirks matching
I think there's timing parameters for higher speed bins which
are different among chips. As we have currently no support
for speed bins higher than DDR50, they're not added yet.
>on
>the H6 compatible string - that's why we put it here already, despite
>having a matching string in the kernel at the moment.
Device tree is not driver data but hardware description, so
it should follow "how the device is formed" rather than
"how the device works".
>
+ reg = <0x0402 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = ;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@4021000 {
+ compatible = "allwinner,sun50i-h6-mmc";
>>>
>>> same here
>>>
+ reg = <0x04021000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = ;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@4022000 {
+ compatible = "allwinner,sun50i-h6-emmc";
>>>
>>> and here:
>>> compatible = "allwinner,sun50i-h6-emmc",
>>> "allwinner,sun50i-a64-emmc";
>>
>> MMC2 on H6 has EMCE capability, so surely there should
>> only be H6 compatible, and no A64 one.
>
>Same as above, the A64 eMMC is a subset of the H6 eMMC, so the A64 eMMC
>driver can drive the H6 as well. And again your code proves that,
>because
[v3 02/10] drm/mediatek: Use regmap for register access
From: Matthias Brugger
The mmsys memory space is shared between the drm and the
clk driver. Use regmap to access it.
Signed-off-by: Matthias Brugger
Reviewed-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 38 +
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 ++--
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 ---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
5 files changed, 24 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 658b8dd45b83..4c65873b4867 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -33,7 +33,7 @@
* @enabled: records whether crtc_enable succeeded
* @planes: array of 4 drm_plane structures, one for each overlay plane
* @pending_planes: whether any plane has pending changes to be applied
- * @config_regs: memory mapped mmsys configuration register space
+ * @config_regs: regmap mapped mmsys configuration register space
* @mutex: handle to one of the ten disp_mutex streams
* @ddp_comp_nr: number of components in ddp_comp
* @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
@@ -48,7 +48,7 @@ struct mtk_drm_crtc {
struct drm_planeplanes[OVL_LAYER_NR];
boolpending_planes;
- void __iomem*config_regs;
+ struct regmap *config_regs;
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..bafc5c77c4fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -185,53 +185,45 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id
cur,
return value;
}
-static void mtk_ddp_sout_sel(void __iomem *config_regs,
+static void mtk_ddp_sout_sel(struct regmap *config_regs,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
{
if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
- writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
- config_regs + DISP_REG_CONFIG_OUT_SEL);
+ regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
+ BLS_TO_DSI_RDMA1_TO_DPI1);
}
-void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
+void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
{
- unsigned int addr, value, reg;
+ unsigned int addr, value;
value = mtk_ddp_mout_en(cur, next, &addr);
- if (value) {
- reg = readl_relaxed(config_regs + addr) | value;
- writel_relaxed(reg, config_regs + addr);
- }
+ if (value)
+ regmap_update_bits(config_regs, addr, value, value);
mtk_ddp_sout_sel(config_regs, cur, next);
value = mtk_ddp_sel_in(cur, next, &addr);
- if (value) {
- reg = readl_relaxed(config_regs + addr) | value;
- writel_relaxed(reg, config_regs + addr);
- }
+ if (value)
+ regmap_update_bits(config_regs, addr, value, value);
}
-void mtk_ddp_remove_comp_from_path(void __iomem *config_regs,
+void mtk_ddp_remove_comp_from_path(struct regmap *config_regs,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
{
- unsigned int addr, value, reg;
+ unsigned int addr, value;
value = mtk_ddp_mout_en(cur, next, &addr);
- if (value) {
- reg = readl_relaxed(config_regs + addr) & ~value;
- writel_relaxed(reg, config_regs + addr);
- }
+ if (value)
+ regmap_update_bits(config_regs, addr, value, 0);
value = mtk_ddp_sel_in(cur, next, &addr);
- if (value) {
- reg = readl_relaxed(config_regs + addr) & ~value;
- writel_relaxed(reg, config_regs + addr);
- }
+ if (value)
+ regmap_update_bits(config_regs, addr, value, 0);
}
struct mtk_disp_mutex *mtk_disp_mutex_get(struct device *dev, unsigned int id)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
index f9a799168077..32e12f33b76a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
@@ -20,10 +20,10 @@ struct regmap;
struct device;
struct mtk_disp_mutex;
-void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
+void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
enum m
[v3 09/10] drm: mediatek: Omit warning on probe defers
From: Matthias Brugger
When probe through the MFD, it can happen that the
clock drivers wasn't probed before the ddp driver gets
invoked. The driver used to omit a warning that the driver
failed to get the clocks. Omit this error on the defered probe path.
Signed-off-by: Matthias Brugger
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index bafc5c77c4fb..6b399348a2dc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -374,7 +374,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
ddp->clk = devm_clk_get(dev, NULL);
if (IS_ERR(ddp->clk)) {
- dev_err(dev, "Failed to get clock\n");
+ if (PTR_ERR(ddp->clk) != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get clock\n");
return PTR_ERR(ddp->clk);
}
--
2.16.3
[v3 05/10] clk: mediatek: mt2701-mm: switch to mfd device
From: Matthias Brugger
As the new mfd device is in place, switch probing
for the MMSYS to support invocation from the mfd device.
Signed-off-by: Matthias Brugger
Acked-by: Stephen Boyd
---
drivers/clk/mediatek/clk-mt2701-mm.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt2701-mm.c
b/drivers/clk/mediatek/clk-mt2701-mm.c
index fe1f85072fc5..4517525887dd 100644
--- a/drivers/clk/mediatek/clk-mt2701-mm.c
+++ b/drivers/clk/mediatek/clk-mt2701-mm.c
@@ -87,16 +87,13 @@ static const struct mtk_gate mm_clks[] = {
GATE_DISP1(CLK_MM_TVE_FMM, "mm_tve_fmm", "mm_sel", 14),
};
-static const struct of_device_id of_match_clk_mt2701_mm[] = {
- { .compatible = "mediatek,mt2701-mmsys", },
- {}
-};
-
static int clk_mt2701_mm_probe(struct platform_device *pdev)
{
struct clk_onecell_data *clk_data;
int r;
- struct device_node *node = pdev->dev.of_node;
+ struct device_node *node;
+
+ node = pdev->dev.parent->of_node;
clk_data = mtk_alloc_clk_data(CLK_MM_NR);
@@ -116,7 +113,6 @@ static struct platform_driver clk_mt2701_mm_drv = {
.probe = clk_mt2701_mm_probe,
.driver = {
.name = "clk-mt2701-mm",
- .of_match_table = of_match_clk_mt2701_mm,
},
};
--
2.16.3
[v3 03/10] mfd: mtk-mmsys: Add mmsys driver
From: Matthias Brugger
The MMSYS subsystem includes clocks and drm components.
This patch adds a MFD device to probe both drivers from the same
device tree compatible.
Signed-off-by: Matthias Brugger
---
drivers/mfd/Kconfig | 9 ++
drivers/mfd/Makefile| 2 ++
drivers/mfd/mtk-mmsys.c | 79 +
3 files changed, 90 insertions(+)
create mode 100644 drivers/mfd/mtk-mmsys.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..d23a3b9a2c58 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -378,6 +378,15 @@ config MFD_MC13XXX_I2C
help
Select this if your MC13xxx is connected via an I2C bus.
+config MFD_MEDIATEK_MMSYS
+ tristate "Mediatek MMSYS interface"
+ select MFD_CORE
+ select REGMAP_MMIO
+ help
+ Select this if you have a MMSYS subsystem in your SoC. The
+ MMSYS subsystem has at least a clock driver part and some
+ DRM components.
+
config MFD_MXS_LRADC
tristate "Freescale i.MX23/i.MX28 LRADC"
depends on ARCH_MXS || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d9d2cf0d32ef..b96118bd68d9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -98,6 +98,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
obj-$(CONFIG_MFD_MC13XXX_SPI) += mc13xxx-spi.o
obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
+obj-$(CONFIG_MFD_MEDIATEK_MMSYS) += mtk-mmsys.o
+
obj-$(CONFIG_MFD_CORE) += mfd-core.o
obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c
new file mode 100644
index ..c802343fb1c6
--- /dev/null
+++ b/drivers/mfd/mtk-mmsys.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * mtk-mmsys.c -- Mediatek MMSYS multi-function driver
+ *
+ * Copyright (c) 2018 Matthias Brugger
+ *
+ * Author: Matthias Brugger
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ MMSYS_MT2701 = 1,
+};
+
+static const struct mfd_cell mmsys_mt2701_devs[] = {
+ { .name = "clk-mt2701-mm", },
+ { .name = "drm-mt2701-mm", },
+};
+
+static int mmsys_probe(struct platform_device *pdev)
+{
+ const struct mfd_cell *mmsys_cells;
+ int nr_cells;
+ long id;
+ int ret;
+
+ id = (long) of_device_get_match_data(&pdev->dev);
+ if (!id) {
+ dev_err(&pdev->dev, "of_device_get match_data() failed\n");
+ return -EINVAL;
+ }
+
+ switch (id) {
+ case MMSYS_MT2701:
+ mmsys_cells = mmsys_mt2701_devs;
+ nr_cells = ARRAY_SIZE(mmsys_mt2701_devs);
+ break;
+ default:
+ return -ENODEV;
+ }
+
+ ret = devm_mfd_add_devices(&pdev->dev, 0, mmsys_cells, nr_cells,
+ NULL, 0, NULL);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to add MFD devices %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+};
+
+static const struct of_device_id of_match_mmsys[] = {
+ { .compatible = "mediatek,mt2701-mmsys",
+ .data = (void *) MMSYS_MT2701,
+ },
+ { /* sentinel */ },
+};
+
+static struct platform_driver mmsys_drv = {
+ .probe = mmsys_probe,
+ .driver = {
+ .name = "mediatek-mmysys",
+ .of_match_table = of_match_ptr(of_match_mmsys),
+ },
+};
+
+builtin_platform_driver(mmsys_drv);
+
+MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver");
+MODULE_LICENSE("GPL");
--
2.16.3
[v3 00/10] arm/arm64: mediatek: Fix mmsys device probing
From: Matthias Brugger Changes since v2: - fix kconfig typo (shame on me) - delete __initconst from mm_clocks as converted to a platform driver Changes since v1: - add binding documentation - ddp: use regmap_update_bits - ddp: ignore EPROBE_DEFER on clock probing - mfd: delete mmsys_private - add Reviewed-by and Acked-by tags --- MMSYS in Mediatek SoCs has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display subsystem. Up to now both drivers, clock and drm are probed with the same device tree compatible. But only the first driver get probed, which in effect breaks graphics on mt8173 and mt2701. This patch set introduces a new mfd device, which binds against the mmsys compatible and takes care of probing the needed devices. It was tested on the bananapi-r2 and the Acer R13 Chromebook. Matthias Brugger (10): dt-bindings: mediatek: mmsys: Add support for mfd drm/mediatek: Use regmap for register access mfd: mtk-mmsys: Add mmsys driver drm/mediatek: mt2701: switch to mfd probing. clk: mediatek: mt2701-mm: switch to mfd device mfd: mtk-mmsys: Add mt8173 nodes drm/mediatek: Add mfd support for mt8173 clk: mediatek: mt8173-mm: switch to mfd device drm: mediatek: Omit warning on probe defers MAINTAINERS: update Mediatek Soc entry .../bindings/arm/mediatek/mediatek,mmsys.txt | 2 - .../bindings/display/mediatek/mediatek,disp.txt| 2 +- .../devicetree/bindings/mfd/mediatek,mmsys.txt | 27 +++ MAINTAINERS| 2 + drivers/clk/mediatek/clk-mt2701-mm.c | 10 +-- drivers/clk/mediatek/clk-mt8173.c | 19 - drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 4 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 41 -- drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 33 drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- drivers/mfd/Kconfig| 9 +++ drivers/mfd/Makefile | 2 + drivers/mfd/mtk-mmsys.c| 93 ++ 14 files changed, 190 insertions(+), 60 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt create mode 100644 drivers/mfd/mtk-mmsys.c -- 2.16.3
[v3 06/10] mfd: mtk-mmsys: Add mt8173 nodes
From: Matthias Brugger
Add devices for the mt8173 SoC.
Signed-off-by: Matthias Brugger
Reviewed-by: Philipp Zabel
---
drivers/mfd/mtk-mmsys.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c
index c802343fb1c6..5585a561a02f 100644
--- a/drivers/mfd/mtk-mmsys.c
+++ b/drivers/mfd/mtk-mmsys.c
@@ -19,6 +19,7 @@
enum {
MMSYS_MT2701 = 1,
+ MMSYS_MT8173,
};
static const struct mfd_cell mmsys_mt2701_devs[] = {
@@ -26,6 +27,12 @@ static const struct mfd_cell mmsys_mt2701_devs[] = {
{ .name = "drm-mt2701-mm", },
};
+static const struct mfd_cell mmsys_mt8173_devs[] = {
+ { .name = "clk-mt8173-mm", },
+ { .name = "drm-mt8173-mm", },
+};
+
+
static int mmsys_probe(struct platform_device *pdev)
{
const struct mfd_cell *mmsys_cells;
@@ -44,6 +51,10 @@ static int mmsys_probe(struct platform_device *pdev)
mmsys_cells = mmsys_mt2701_devs;
nr_cells = ARRAY_SIZE(mmsys_mt2701_devs);
break;
+ case MMSYS_MT8173:
+ mmsys_cells = mmsys_mt8173_devs;
+ nr_cells = ARRAY_SIZE(mmsys_mt8173_devs);
+ break;
default:
return -ENODEV;
}
@@ -62,6 +73,9 @@ static const struct of_device_id of_match_mmsys[] = {
{ .compatible = "mediatek,mt2701-mmsys",
.data = (void *) MMSYS_MT2701,
},
+ { .compatible = "mediatek,mt8173-mmsys",
+ .data = (void *) MMSYS_MT8173,
+ },
{ /* sentinel */ },
};
--
2.16.3
[v3 07/10] drm/mediatek: Add mfd support for mt8173
From: Matthias Brugger
Use the MFD device for SoC mt8173. Probing via devicetree
is no longer needed for any SoC, so delete it.
Signed-off-by: Matthias Brugger
Reviewed-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 88ee35907744..3cc433ebfa8f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -399,20 +399,12 @@ static int mtk_drm_probe(struct platform_device *pdev)
INIT_WORK(&private->commit.work, mtk_atomic_work);
private->data = of_device_get_match_data(dev);
- /* Check if called from mfd */
- if (!dev->of_node) {
- mmsys_node = pdev->dev.parent->of_node;
- private->data = (struct mtk_mmsys_driver_data *)
- platform_get_device_id(pdev)->driver_data;
- private->config_regs =
- syscon_node_to_regmap(mmsys_node);
- parent_node = mmsys_node->parent;
- } else {
- private->config_regs = syscon_node_to_regmap(dev->of_node);
- if (IS_ERR(private->config_regs))
- return PTR_ERR(private->config_regs);
- parent_node = dev->of_node->parent;
- }
+ mmsys_node = pdev->dev.parent->of_node;
+ private->data = (struct mtk_mmsys_driver_data *)
+ platform_get_device_id(pdev)->driver_data;
+ private->config_regs =
+ syscon_node_to_regmap(mmsys_node);
+ parent_node = mmsys_node->parent;
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(parent_node, node) {
@@ -555,14 +547,9 @@ static int mtk_drm_sys_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
mtk_drm_sys_resume);
-static const struct of_device_id mtk_drm_of_ids[] = {
- { .compatible = "mediatek,mt8173-mmsys",
- .data = &mt8173_mmsys_driver_data},
- { }
-};
-
static const struct platform_device_id mtk_drm_ids[] = {
{ "drm-mt2701-mm", (kernel_ulong_t)&mt2701_mmsys_driver_data },
+ { "drm-mt8173-mm", (kernel_ulong_t)&mt8173_mmsys_driver_data },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(platform, mtk_drm_ids);
@@ -572,7 +559,6 @@ static struct platform_driver mtk_drm_platform_driver = {
.remove = mtk_drm_remove,
.driver = {
.name = "mediatek-drm",
- .of_match_table = mtk_drm_of_ids,
.pm = &mtk_drm_pm_ops,
},
.id_table = mtk_drm_ids,
--
2.16.3
[v3 10/10] MAINTAINERS: update Mediatek Soc entry
From: Matthias Brugger Mediatek SoCs include several soc specific drivers as well as a mfd device. Add these to the maintainers file. Signed-off-by: Matthias Brugger --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0a1410d5a621..74f7ea345096 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1621,6 +1621,8 @@ F:arch/arm/boot/dts/mt7* F: arch/arm/boot/dts/mt8* F: arch/arm/mach-mediatek/ F: arch/arm64/boot/dts/mediatek/ +F: drivers/soc/mediatek/ +F: drivers/mfd/mtk-mmsys.c N: mtk K: mediatek -- 2.16.3
[v3 04/10] drm/mediatek: mt2701: switch to mfd probing.
From: Matthias Brugger
With the mtk-mmsys MFD device in place, we switch the probing for
mt2701 from device-tree to mfd.
Signed-off-by: Matthias Brugger
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a48e28adad09..88ee35907744 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -386,7 +386,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct mtk_drm_private *private;
- struct device_node *node;
+ struct device_node *node, *parent_node, *mmsys_node;
struct component_match *match = NULL;
int ret;
int i;
@@ -399,12 +399,23 @@ static int mtk_drm_probe(struct platform_device *pdev)
INIT_WORK(&private->commit.work, mtk_atomic_work);
private->data = of_device_get_match_data(dev);
- private->config_regs = syscon_node_to_regmap(dev->of_node);
- if (IS_ERR(private->config_regs))
- return PTR_ERR(private->config_regs);
+ /* Check if called from mfd */
+ if (!dev->of_node) {
+ mmsys_node = pdev->dev.parent->of_node;
+ private->data = (struct mtk_mmsys_driver_data *)
+ platform_get_device_id(pdev)->driver_data;
+ private->config_regs =
+ syscon_node_to_regmap(mmsys_node);
+ parent_node = mmsys_node->parent;
+ } else {
+ private->config_regs = syscon_node_to_regmap(dev->of_node);
+ if (IS_ERR(private->config_regs))
+ return PTR_ERR(private->config_regs);
+ parent_node = dev->of_node->parent;
+ }
/* Iterate over sibling DISP function blocks */
- for_each_child_of_node(dev->of_node->parent, node) {
+ for_each_child_of_node(parent_node, node) {
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -545,13 +556,17 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops,
mtk_drm_sys_suspend,
mtk_drm_sys_resume);
static const struct of_device_id mtk_drm_of_ids[] = {
- { .compatible = "mediatek,mt2701-mmsys",
- .data = &mt2701_mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
.data = &mt8173_mmsys_driver_data},
{ }
};
+static const struct platform_device_id mtk_drm_ids[] = {
+ { "drm-mt2701-mm", (kernel_ulong_t)&mt2701_mmsys_driver_data },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mtk_drm_ids);
+
static struct platform_driver mtk_drm_platform_driver = {
.probe = mtk_drm_probe,
.remove = mtk_drm_remove,
@@ -560,6 +575,7 @@ static struct platform_driver mtk_drm_platform_driver = {
.of_match_table = mtk_drm_of_ids,
.pm = &mtk_drm_pm_ops,
},
+ .id_table = mtk_drm_ids,
};
static struct platform_driver * const mtk_drm_drivers[] = {
--
2.16.3
[v3 08/10] clk: mediatek: mt8173-mm: switch to mfd device
From: Matthias Brugger
As the new mfd device is in place, switch probing
for the MMSYS to support invocation from the mfd device.
Signed-off-by: Matthias Brugger
Acked-by: Stephen Boyd
---
drivers/clk/mediatek/clk-mt8173.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 96c292c3e440..e31b3ee3e968 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "clk-mtk.h"
#include "clk-gate.h"
@@ -791,7 +792,7 @@ static const struct mtk_gate_regs mm1_cg_regs __initconst =
{
.ops = &mtk_clk_gate_ops_setclr,\
}
-static const struct mtk_gate mm_clks[] __initconst = {
+static const struct mtk_gate mm_clks[] = {
/* MM0 */
GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
@@ -1152,10 +1153,13 @@ static void __init mtk_imgsys_init(struct device_node
*node)
}
CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt8173-imgsys", mtk_imgsys_init);
-static void __init mtk_mmsys_init(struct device_node *node)
+static int mtk_mmsys_probe(struct platform_device *pdev)
{
struct clk_onecell_data *clk_data;
int r;
+ struct device_node *node;
+
+ node = pdev->dev.parent->of_node;
clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
@@ -1166,8 +1170,17 @@ static void __init mtk_mmsys_init(struct device_node
*node)
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+ return r;
}
-CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt8173-mmsys", mtk_mmsys_init);
+
+static struct platform_driver clk_mt8173_mm_drv = {
+ .probe = mtk_mmsys_probe,
+ .driver = {
+ .name = "clk-mt8173-mm",
+ },
+};
+builtin_platform_driver(clk_mt8173_mm_drv);
static void __init mtk_vdecsys_init(struct device_node *node)
{
--
2.16.3
