[PATCH] Staging: gdm724x: mux: Check return value of register_lte_tty_driver().
Check the return value of of the register_lte_tty_driver() call in the
module initialization function.
Signed-off-by: Quytelda Kahja
---
drivers/staging/gdm724x/gdm_mux.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/gdm724x/gdm_mux.c
b/drivers/staging/gdm724x/gdm_mux.c
index 996b1f538aae..63921bad519e 100644
--- a/drivers/staging/gdm724x/gdm_mux.c
+++ b/drivers/staging/gdm724x/gdm_mux.c
@@ -657,7 +657,11 @@ static struct usb_driver gdm_mux_driver = {
static int __init gdm_usb_mux_init(void)
{
- register_lte_tty_driver();
+ int ret;
+
+ ret = register_lte_tty_driver();
+ if (ret)
+ return ret;
return usb_register(&gdm_mux_driver);
}
--
2.16.1
Re: [PATCH 1/3] taint: Convert to enum and indexed initialization
Hi Kees, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc1 next-20180216] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Kees-Cook/taint-Add-taint-for-randstruct/20180218-100113 config: arm64-defconfig (attached as .config) compiler: aarch64-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=arm64 All errors (new ones prefixed by >>): /tmp/ccUwVEny.s: Assembler messages: >> /tmp/ccUwVEny.s:897: Error: invalid operands (*UND* and *ABS* sections) for >> `<<' /tmp/ccUwVEny.s:932: Error: invalid operands (*UND* and *ABS* sections) for `<<' /tmp/ccUwVEny.s:1116: Error: invalid operands (*UND* and *ABS* sections) for `<<' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] gpiolib: suppress error message on EPROBE_DEFER
On 02/07/2018 06:57 AM, Linus Walleij wrote: On Sun, Jan 21, 2018 at 9:32 PM, David Lechner wrote: This suppresses printing an error message during probe of gpio drivers when the error is EPROBE_DEFER. Cc: Linus Walleij Signed-off-by: David Lechner I'm not sure about this. GPIO can be very basic system components. If we don't print this, defer a few times (for some reason) and then the kernel gives up on retrying, silently (as it happens) there is no trace in dmesg of what happened. That makes things hard to debug. This happened to me with some other driver, so it is not a made up example. What about an explicit deferral message for now? so you mean something like this? if (err == -EPROBE_DEFER) dev_info(dev, "deferring probe\n") else dev_err(dev, "... failed to register\n")
Re: [PATCH 0/7] ARM: davinci: add genpd support
On 02/09/2018 06:42 AM, Sekhar Nori wrote: Hi David, On Thursday 08 February 2018 04:13 AM, David Lechner wrote: On 02/07/2018 07:45 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Hi Sekhar et al, please take a look at the following patches. They add a simple genpd driver and use it in DT mode on da850 boards. I was trying to use genpd in legacy mode too, but couldn't find neither any interfaces nor users that would do that. For now I added a check in arch/arm/mach-davinci/pm_domain.c that disables the clock pm setup if we're using genpd. This series applies on top of and has been tested with David Lechner's for-bartosz branch. It fixes the clock look-up issues we faced with lcdc and emac. I'm starting to think that it makes more sense to just make the PSC driver a power-domain and reset provider rather than a clock provider. It is unfortunate that genpd is DT only. This will mean that the only way to enable clocks on DaVinci is to use pm_runtime() calls. We do still have drivers which depend on clk api for enabling clocks, so I am not sure its feasible just yet. I think a question like this can arise for any gate clock. I've incorporated parts of this series into my v7 work in progress using the suggestions I made about using the existing PSC device as the power domain provider.
Re: [PATCH] objtool/x86: Replace Non-standard Range Expression in Case
On Fri, 2018-02-16 at 17:47 +0100, Peter Zijlstra wrote: > On Fri, Feb 16, 2018 at 08:35:11AM -0600, Josh Poimboeuf wrote: > > On Fri, Feb 16, 2018 at 07:55:13PM +0530, Progyan Bhattacharya > > wrote: > > > Replace range expressions with seperate individual cases, i.e. > > > convert case 1...3: to case 1: case 2: case 3 > > > Range expression within case statements are non-standard C code > > > and can create issues over compiler and platform variety. > > > > > > While compiling with gcc 4.8 (RHEL) I encountered this error on > > > range expression in case statements: > > > error: range expressions in switch statements are non-standard [- > > > Werror=pedantic] > > > > > > Signed-off-by: Progyan Bhattacharya > > > > Hi Progyan, > > > > Thank you for the patch. > > > > I think this makes the code unnecessarily verbose and less > > readable. We > > rely on many such GCC extensions, and we don't aim to comply with > > standard C. And AFAIK, we don't use -Werror=pedantic in the > > kernel. > > Agreed, it makes the code actively worse. Just don't use > error=pedantic. But I cannot figure it out how Werror=pedantic flag is being set. :( -- Regards, Progyan Bhattacharya (http://codeprogyan.me)
Re: [PATCH] MIPS: pm-cps: Block system suspend when a JTAG probe is present
Hi Matt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc1 next-20180216]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Matt-Redfearn/MIPS-pm-cps-Block-system-suspend-when-a-JTAG-probe-is-present/20180218-082248
config: mips-64r6el_defconfig (attached as .config)
compiler: mips64el-linux-gnuabi64-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=mips
All errors (new ones prefixed by >>):
arch/mips//kernel/pm-cps.c: In function 'cps_pm_power_notifier':
>> arch/mips//kernel/pm-cps.c:693:14: error: 'CPC_Cx_STAT_CONF_EJTAG_PROBE_MSK'
>> undeclared (first use in this function); did you mean
>> 'CPC_Cx_STAT_CONF_EJTAG_PROBE'?
if (stat & CPC_Cx_STAT_CONF_EJTAG_PROBE_MSK) {
^~~~
CPC_Cx_STAT_CONF_EJTAG_PROBE
arch/mips//kernel/pm-cps.c:693:14: note: each undeclared identifier is
reported only once for each function it appears in
vim +693 arch/mips//kernel/pm-cps.c
673
674 #if defined(CONFIG_PM_SLEEP)
675 static int cps_pm_power_notifier(struct notifier_block *this,
676 unsigned long event, void *ptr)
677 {
678 unsigned int stat;
679
680 switch (event) {
681 case PM_SUSPEND_PREPARE:
682 stat = read_cpc_cl_stat_conf();
683 /*
684 * If we're attempting to suspend the system and power
down all
685 * of the cores, the JTAG detect bit indicates that the
CPC will
686 * instead put the cores into clock-off state. In this
state
687 * a connected debugger can cause the CPU to attempt
688 * interactions with the powered down system. At best
this will
689 * fail. At worst, it can hang the NoC, requiring a
hard reset.
690 * To avoid this, just block system suspend if a JTAG
probe
691 * is detected.
692 */
> 693 if (stat & CPC_Cx_STAT_CONF_EJTAG_PROBE_MSK) {
694 pr_warn("JTAG probe is connected - abort
suspend\n");
695 return NOTIFY_BAD;
696 }
697 return NOTIFY_DONE;
698 default:
699 return NOTIFY_DONE;
700 }
701 }
702 #endif /* CONFIG_PM_SLEEP */
703
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v2] ARM: da8xx: use platform data for CFGCHIP syscon regmap
This converts from using a platform device for the CFGCHIP syscon
regmap to using platform data to pass the regmap to consumers.
A lazy getter function is used so that the regmap will only be
created if it is actually used. This function will also be used
in the clock init when we convert to the common clock framework.
The USB PHY driver is currently the only consumer. This driver is
updated to use platform data to get the CFGCHIP regmap instead of
syscon_regmap_lookup_by_pdevname().
Signed-off-by: David Lechner >
Acked-by: Kishon Vijay Abraham I
---
v2 changes:
- add #ifndef/#define to header file
arch/arm/mach-davinci/board-da830-evm.c | 4 ---
arch/arm/mach-davinci/board-da850-evm.c | 4 ---
arch/arm/mach-davinci/board-mityomapl138.c | 4 ---
arch/arm/mach-davinci/board-omapl138-hawk.c | 4 ---
arch/arm/mach-davinci/devices-da8xx.c | 45 +++--
arch/arm/mach-davinci/include/mach/da8xx.h | 3 +-
arch/arm/mach-davinci/usb-da8xx.c | 6
drivers/phy/ti/phy-da8xx-usb.c | 8 +++--
include/linux/platform_data/phy-da8xx-usb.h | 21 ++
9 files changed, 58 insertions(+), 41 deletions(-)
create mode 100644 include/linux/platform_data/phy-da8xx-usb.h
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 7aa1262..004f9c8 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -551,10 +551,6 @@ static __init void da830_evm_init(void)
struct davinci_soc_info *soc_info = &davinci_soc_info;
int ret;
- ret = da8xx_register_cfgchip();
- if (ret)
- pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da830_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d9d423d..3063478 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1334,10 +1334,6 @@ static __init void da850_evm_init(void)
{
int ret;
- ret = da8xx_register_cfgchip();
- if (ret)
- pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da850_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c
b/arch/arm/mach-davinci/board-mityomapl138.c
index f9a725a..d1c8548 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -502,10 +502,6 @@ static void __init mityomapl138_init(void)
{
int ret;
- ret = da8xx_register_cfgchip();
- if (ret)
- pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
/* for now, no special EDMA channels are reserved */
ret = da850_register_edma(NULL);
if (ret)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index bc8a747..e2ba9da 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -281,10 +281,6 @@ static __init void omapl138_hawk_init(void)
{
int ret;
- ret = da8xx_register_cfgchip();
- if (ret)
- pr_warn("%s: CFGCHIP registration failed: %d\n", __func__, ret);
-
ret = da850_register_gpio();
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index fe5e15a..24422ba 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -11,7 +11,6 @@
* (at your option) any later version.
*/
#include
-#include
#include
#include
#include
@@ -1105,29 +1104,33 @@ int __init da850_register_sata(unsigned long refclkpn)
}
#endif
-static struct syscon_platform_data da8xx_cfgchip_platform_data = {
- .label = "cfgchip",
-};
+static struct regmap *da8xx_cfgchip;
-static struct resource da8xx_cfgchip_resources[] = {
- {
- .start = DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP0_REG,
- .end= DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP4_REG + 3,
- .flags = IORESOURCE_MEM,
- },
-};
+/* regmap doesn't make a copy of this, so we need to keep the pointer around */
+static const char da8xx_cfgchip_name[] = "cfgchip";
-static struct platform_device da8xx_cfgchip_device = {
- .name = "syscon",
- .id = -1,
- .dev= {
- .platform_data = &da8xx_cfgchip_platform_data,
- },
- .num_resources = ARRAY_SIZE(da8xx_cfgchip_resources),
- .resource = da8xx_cfgchip_resources,
+static const struct regmap_config da8xx_cfgchip_config __initconst = {
+ .name = da8xx_cfgchip_name,
+
Re: [PATCH v3 1/4] of: change overlay apply input data from unflattened to FDT
Hi Frank,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.16-rc1 next-20180216]
[cannot apply to glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/frowand-list-gmail-com/of-change-overlay-apply-input-data-from-unflattened/20180218-095108
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-randconfig-x018-201807 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/of/overlay.c: In function 'of_overlay_fdt_apply':
>> drivers/of/overlay.c:832:2: error: implicit declaration of function
>> 'of_fdt_unflatten_tree' [-Werror=implicit-function-declaration]
of_fdt_unflatten_tree(new_fdt, NULL, &overlay_root);
^
cc1: some warnings being treated as errors
vim +/of_fdt_unflatten_tree +832 drivers/of/overlay.c
806
807 int of_overlay_fdt_apply(void *overlay_fdt, int *ovcs_id)
808 {
809 const void *new_fdt;
810 int ret;
811 u32 size;
812 struct device_node *overlay_root;
813
814 *ovcs_id = 0;
815 ret = 0;
816
817 if (fdt_check_header(overlay_fdt)) {
818 pr_err("Invalid overlay_fdt header\n");
819 return -EINVAL;
820 }
821
822 size = fdt_totalsize(overlay_fdt);
823
824 /*
825 * Must create permanent copy of FDT because
of_fdt_unflatten_tree()
826 * will create pointers to the passed in FDT in the unflattened
tree.
827 */
828 new_fdt = kmemdup(overlay_fdt, size, GFP_KERNEL);
829 if (!new_fdt)
830 return -ENOMEM;
831
> 832 of_fdt_unflatten_tree(new_fdt, NULL, &overlay_root);
833 if (!overlay_root) {
834 pr_err("unable to unflatten overlay_fdt\n");
835 ret = -EINVAL;
836 goto out_free_new_fdt;
837 }
838
839 ret = of_overlay_apply(new_fdt, overlay_root, ovcs_id);
840 if (ret < 0) {
841 /*
842 * new_fdt and overlay_root now belong to the overlay
843 * changeset.
844 * overlay changeset code is responsible for freeing
them.
845 */
846 goto out;
847 }
848
849 return 0;
850
851
852 out_free_new_fdt:
853 kfree(new_fdt);
854
855 out:
856 return ret;
857 }
858 EXPORT_SYMBOL_GPL(of_overlay_fdt_apply);
859
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
RE: [PATCH v4 07/24] fpga: dfl: add feature device infrastructure
> On Thu, Feb 15, 2018 at 10:05:20AM +, Wu, Hao wrote:
> > > On Wed, Feb 14, 2018 at 3:03 PM, Moritz Fischer wrote:
> > >
> > > Hi Moritz,
> > >
> > > > HI Hao,
> > > >
> >
> > Hi Alan and Moritz
> >
> > Thanks a lot for the code review and comments.
> >
> > > > On Tue, Feb 13, 2018 at 05:24:36PM +0800, Wu Hao wrote:
> > > >> From: Xiao Guangrong
> > > >>
> > > >> This patch abstracts the common operations of the sub features, and
> defines
> > > >> the feature_ops data structure, including init, uinit and ioctl
> > > >> function
> > > >> pointers. And this patch adds some common helper functions for FME and
> > > AFU
> > > >> drivers, e.g feature_dev_use_begin/end which are used to ensure
> exclusive
> > > >> usage of the feature device file.
> > > >>
> > > >> Signed-off-by: Tim Whisonant
> > > >> Signed-off-by: Enno Luebbers
> > > >> Signed-off-by: Shiva Rao
> > > >> Signed-off-by: Christopher Rauer
> > > >> Signed-off-by: Kang Luwei
> > > >> Signed-off-by: Zhang Yi
> > > >> Signed-off-by: Xiao Guangrong
> > > >> Signed-off-by: Wu Hao
> > > >> ---
> > > >> v2: rebased
> > > >> v3: use const for feature_ops.
> > > >> replace pci related function.
> > > >> v4: rebase and add more comments in code.
> > > >> ---
> > > >> drivers/fpga/dfl.c | 59 +
> > > >> drivers/fpga/dfl.h | 85
> > > +-
> > > >> 2 files changed, 143 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> > > >> index 38dc819..c0aad87 100644
> > > >> --- a/drivers/fpga/dfl.c
> > > >> +++ b/drivers/fpga/dfl.c
> > > >> @@ -74,6 +74,65 @@ static enum fpga_id_type
> feature_dev_id_type(struct
> > > platform_device *pdev)
> > > >> return FPGA_ID_MAX;
> > > >> }
> > > >>
> > > >> +void fpga_dev_feature_uinit(struct platform_device *pdev)
> > > >> +{
> > > >> + struct feature *feature;
> > > >> + struct feature_platform_data *pdata = dev_get_platdata(&pdev-
> >dev);
> > > > See comment below w.r.t ordering declarations. Not a must for sure.
> > > >> +
> > > >> + fpga_dev_for_each_feature(pdata, feature)
> > > >> + if (feature->ops) {
> > > >> + feature->ops->uinit(pdev, feature);
> > > >> + feature->ops = NULL;
> > > >> + }
> > > >> +}
> > > >> +EXPORT_SYMBOL_GPL(fpga_dev_feature_uinit);
> > > >> +
> > > >> +static int
> > > >> +feature_instance_init(struct platform_device *pdev,
> > > >> + struct feature_platform_data *pdata,
> > > >> + struct feature *feature, struct feature_driver
> > > >> *drv)
> > > >> +{
> > > >> + int ret;
> > > >> +
> > > >> + WARN_ON(!feature->ioaddr);
> > > >
> > > > Not sure I understand correctly, is the !feature->ioaddr a use-case that
> > > > happens? If not just return early.
> >
> > Actually this should never happen (init a feature without mapped mmio
> > resource address). If this warning is seen, that means there should be
> > critical issues somewhere in driver enumeration code. But sure, I can just
> > use if () return instead. : )
> >
> > > >> +
> > > >> + ret = drv->ops->init(pdev, feature);
> > > >> + if (ret)
> > > >> + return ret;
> > > >> +
> > > >> + feature->ops = drv->ops;
> > > >> +
> > > >> + return ret;
> > > >> +}
> > > >> +
> > > >> +int fpga_dev_feature_init(struct platform_device *pdev,
> > > >> + struct feature_driver *feature_drvs)
> > > >> +{
> > > >> + struct feature *feature;
> > > >> + struct feature_driver *drv = feature_drvs;
> > > >> + struct feature_platform_data *pdata = dev_get_platdata(&pdev-
> >dev);
> > > >> + int ret;
> > > > We don't have clear guidelines here, but some subsystems want reverse
> > > > X-Mas tree declarations.
> > >
> > > Sounds good! I agree.
> >
> > Do you mean we should reverse fpga_xxx definitions? If yes, then I can
> > update
> > the code to use fpga_dfl_xxx or dfl_xxx instead. : )
>
> More a stylistic thing, in the sense that you'd have the longest line
> first:
>
> + struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> + struct feature_driver *drv = feature_drvs;
> + struct feature *feature;
> + int ret;
>
> Instead of:
>
> + struct feature *feature;
> + struct feature_driver *drv = feature_drvs;
> + struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> + int ret;
>
> as I said not a big deal, some subsystems want you to do this, I don't
> think we made that a strict rule so far, but it makes it visually more
> pleasing ;-)
Oh.. I see. Thanks for the suggestion, I will update the patch for this.
Hao
>
> Moritz
Re: [PATCH -mm -v5 RESEND] mm, swap: Fix race between swapoff and some swap operations
On Sat, Feb 17, 2018 at 7:38 AM, Andrew Morton
wrote:
> On Wed, 14 Feb 2018 08:38:00 +0800 "Huang\, Ying"
> wrote:
>
>> Andrew Morton writes:
>>
>> > On Tue, 13 Feb 2018 09:42:20 +0800 "Huang, Ying"
>> > wrote:
>> >
>> >> From: Huang Ying
>> >>
>> >> When the swapin is performed, after getting the swap entry information
>> >> from the page table, system will swap in the swap entry, without any
>> >> lock held to prevent the swap device from being swapoff. This may
>> >> cause the race like below,
>> >
>> > Sigh. In terms of putting all the work into the swapoff path and
>> > avoiding overheads in the hot paths, I guess this is about as good as
>> > it will get.
>> >
>> > It's a very low-priority fix so I'd prefer to keep the patch in -mm
>> > until Hugh has had an opportunity to think about it.
>> >
>> >> ...
>> >>
>> >> +/*
>> >> + * Check whether swap entry is valid in the swap device. If so,
>> >> + * return pointer to swap_info_struct, and keep the swap entry valid
>> >> + * via preventing the swap device from being swapoff, until
>> >> + * put_swap_device() is called. Otherwise return NULL.
>> >> + */
>> >> +struct swap_info_struct *get_swap_device(swp_entry_t entry)
>> >> +{
>> >> + struct swap_info_struct *si;
>> >> + unsigned long type, offset;
>> >> +
>> >> + if (!entry.val)
>> >> + goto out;
>> >> + type = swp_type(entry);
>> >> + if (type >= nr_swapfiles)
>> >> + goto bad_nofile;
>> >> + si = swap_info[type];
>> >> +
>> >> + preempt_disable();
>> >
>> > This preempt_disable() is later than I'd expect. If a well-timed race
>> > occurs, `si' could now be pointing at a defunct entry. If that
>> > well-timed race include a swapoff AND a swapon, `si' could be pointing
>> > at the info for a new device?
>>
>> struct swap_info_struct pointed to by swap_info[] will never be freed.
>> During swapoff, we only free the memory pointed to by the fields of
>> struct swap_info_struct. And when swapon, we will always reuse
>> swap_info[type] if it's not NULL. So it should be safe to dereference
>> swap_info[type] with preemption enabled.
>
> That's my point. If there's a race window during which there is a
> parallel swapoff+swapon, this swap_info_struct may now be in use for a
> different device?
Yes. It's possible. And the caller of get_swap_device() can live
with it if the swap_info_struct has been fully initialized. For
example, for the race in the patch description,
do_swap_page
swapin_readahead
__read_swap_cache_async
swapcache_prepare
__swap_duplicate
in __swap_duplicate(), it's possible that the swap device returned by
get_swap_device() is different from the swap device when
__swap_duplicate() call get_swap_device(). But the struct_info_struct
has been fully initialized, so __swap_duplicate() can reference
si->swap_map[] safely. And we will check si->swap_map[] before any
further operation. Even if the swap entry is swapped out again for
the new swap device, we will check the page table again in
do_swap_page(). So there is no functionality problem.
Best Regards,
Huang, Ying
Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description
On Sat, 2018-02-17 at 16:26 -0800, h...@zytor.com wrote: > Do you have a description of the gaps you have identified? Probably the 2016 Linux Security Summit (LSS) integrity status update has the best list. http://events17.linuxfoundation.org/sites/events/files/slides/LSS2016- LinuxIntegritySubsystemStatus.pdf Mimi
Re: [PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4
Hi Tony,
On Sat, Feb 17, 2018 at 01:07:23PM -0800, Tony Lindgren wrote:
> Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> It is used on some Motorola Mapphone series of phones and tablets such
> as Droid 4.
>
> The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
> is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
> device it seems. We know this as we get L3 errors from omap-usb-host if
> trying to use the PHY before MDM6600 is configured.
>
> The GPIOs controlling MDM6600 are used to power MDM660 on and off, to
> configure the USB start-up mode (normal mode versus USB flashing), and
> they also tell the state of the MDM6600 device.
>
> The two start-up mode GPIOs are dual-purposed and used for out of band
> (OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
> the USB start-up mode first to get MDM6600 booted in the right mode to
> be usable in the first place.
>
> For now, this driver just gives up the two start-up mode GPIOs after the
> modem has been configured to boot in normal mode. One of them we may
> want to configure for USB OOB wake in this driver later on, but that's a
> separate series of patches and needs more work.
>
> Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
> driver for modems. But it really does not control the radio at all, it
> just controls the modem power and start-up mode for USB. So I came to
> the conclusion that we're better off having this done in the USB PHY
> driver. For adding support for USB flashing mode, we can later on add
> a kernel module option for flash_mode=1 or something similar.
>
> Also note that currently there is no PM runtime support for the OHCI
> on omap variant SoCs. So for low(er) power idle states, currenty both
> ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.
>
> For reference here is what I measured for total power consumption on
> an idle Droid 4 with and without USB related MDM6600 modules:
>
> idle lcd off phy-mapphone-mdm6600ohci-platform
> 153mW 284mW 344mW
So more than twice the idle power... We really want to get runtime
PM working :/
> So it seems that MDM6600 is currently not yet idling even with it's
> radio turned off, but that's something that is beyond the control of
> this USB PHY driver.
>
> Cc: devicet...@vger.kernel.org
> Cc: Mark Rutland
> Cc: Marcel Partap
> Cc: Michael Scott
> Cc: Rob Herring
> Cc: Sebastian Reichel
> Signed-off-by: Tony Lindgren
> ---
> .../bindings/phy/phy-mapphone-mdm6600.txt | 30 ++
> drivers/phy/motorola/Kconfig | 9 +
> drivers/phy/motorola/Makefile | 1 +
> drivers/phy/motorola/phy-mapphone-mdm6600.c| 490
> +
> 4 files changed, 530 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> @@ -0,0 +1,30 @@
> +Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
> +
> +Required properties:
> +- compatible Must be "motorola,mapphone-mdm6600"
> +- enable-gpios GPIO to enable the USB PHY
> +- power-gpiosGPIO to power on the device
> +- reset-gpiosGPIO to reset the device
> +- mode-gpios Two GPIOs to configure MDM6600 USB start-up mode for
> + normal mode versus USB flashing mode
> +- status-gpios Three GPIOs to read the power state of the MDM6600
> +- cmd-gpios Three GPIOs to control the power state of the MDM6600
> +
> +Example:
> +
> +fsusb1_phy: fsusb1_phy {
> + compatible = "motorola,mapphone-mdm6600";
> + enable-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>; /* gpio_95 */
> + power-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>; /* gpio_54 */
> + reset-gpios = <&gpio2 17 GPIO_ACTIVE_HIGH>; /* gpio_49 */
> + mode-gpios = <&gpio5 20 GPIO_ACTIVE_HIGH>, /* gpio_148 */
> + <&gpio5 21 GPIO_ACTIVE_HIGH>; /* gpio_149 */
> + status-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>,/* gpio_55 */
> +<&gpio2 21 GPIO_ACTIVE_HIGH>,/* gpio_53 */
> +<&gpio2 20 GPIO_ACTIVE_HIGH>;/* gpio_52 */
> + cmd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>,/* gpio_103 */
> + <&gpio4 8 GPIO_ACTIVE_HIGH>,/* gpio_104 */
> + <&gpio5 14 GPIO_ACTIVE_HIGH>; /* gpio_142 */
> + #phy-cells = <0>;
> +};
> +
> diff --git a/drivers/phy/motorola/Kconfig b/drivers/phy/motorola/Kconfig
> --- a/drivers/phy/motorola/Kconfig
> +++ b/drivers/phy/motorola/Kconfig
> @@ -10,3 +10,12 @@ config PHY_CPCAP_USB
> help
> Enabl
Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description
On February 17, 2018 4:15:12 PM PST, Mimi Zohar wrote: >On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote: >> On 02/16/18 12:33, Taras Kondratiuk wrote: >> > Many of the Linux security/integrity features are dependent on file >> > metadata, stored as extended attributes (xattrs), for making >decisions. >> > These features need to be initialized during initcall and enabled >as >> > early as possible for complete security coverage. >> > >> > Initramfs (tmpfs) supports xattrs, but newc CPIO archive format >does not >> > support including them into the archive. >> > >> > This patch describes "extended" newc format (newcx) that is based >on >> > newc and has following changes: >> > - extended attributes support >> > - increased size of filesize to support files >4GB >> > - increased mtime field size to have 64 bits of seconds and added a >> > field for nanoseconds >> > - removed unused checksum field >> > >> >> If you are going to implement a new, non-backwards-compatible format, >> you shouldn't replicate the mistakes of the current format. >Specifically: >> >> 1. The use of ASCII-encoded fixed-length numbers is an idiotic legacy >> from an era before there were any portable way of dealing with >numbers >> with prespecified endianness. If you are going to use ASCII, make >them >> delimited so that they don't have fixed limits, or just use binary. >> >> The cpio header isn't fixed size, so that argument goes away, in fact >> the only way to determine the end of the header is to scan forward. >> >> 2. Alignment sensitivity! Because there is no header length >> information, the above scan tells you where the header ends, but >there >> is padding before the data, and the size of that padding is only >defined >> by alignment. >> >> 3. Inband encoding of EOF: if you actually have a filename >"TRAILER!!!" >> you have problems. >> >> But first, before you define a whole new format for which no tools >exist >> (you will have to work with the maintainers of the GNU tools to add >> support) you should see how complex it would be to support the POSIX >> tar/pax format, which already has all the features you are seeking, >and >> by now is well-supported. > >The discussion about including xattrs in the initramfs didn't start >yesterday. It's been on the list of measurement/appraisal gaps that >need to be closed for years. Initially I planned on using tar, but at >the 2014 Kernel Summit I spoke with Al at length. At the time, he was >very clear that tar is unnecessarily overly complicated and >recommended extending CPIO. > >I took his advice. Unfortunately, as soon as I posted an initial >patch set to include xattrs in CPIO, all of the problems with CPIO had >to be addressed before defining a new CPIO number. Unfortunately, >this wasn't the only measurement/appraisal gap that needed to be >addressed. I've been working on closing other gaps. > >I'm really happy that someone has taken the time to work on this. > Instead of derailing their attempt of extending CPIO to include >xattrs, I'd appreciate your making constructive suggestions. > >Mimi Do you have a description of the gaps you have identified? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description
On February 17, 2018 4:15:12 PM PST, Mimi Zohar wrote: >On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote: >> On 02/16/18 12:33, Taras Kondratiuk wrote: >> > Many of the Linux security/integrity features are dependent on file >> > metadata, stored as extended attributes (xattrs), for making >decisions. >> > These features need to be initialized during initcall and enabled >as >> > early as possible for complete security coverage. >> > >> > Initramfs (tmpfs) supports xattrs, but newc CPIO archive format >does not >> > support including them into the archive. >> > >> > This patch describes "extended" newc format (newcx) that is based >on >> > newc and has following changes: >> > - extended attributes support >> > - increased size of filesize to support files >4GB >> > - increased mtime field size to have 64 bits of seconds and added a >> > field for nanoseconds >> > - removed unused checksum field >> > >> >> If you are going to implement a new, non-backwards-compatible format, >> you shouldn't replicate the mistakes of the current format. >Specifically: >> >> 1. The use of ASCII-encoded fixed-length numbers is an idiotic legacy >> from an era before there were any portable way of dealing with >numbers >> with prespecified endianness. If you are going to use ASCII, make >them >> delimited so that they don't have fixed limits, or just use binary. >> >> The cpio header isn't fixed size, so that argument goes away, in fact >> the only way to determine the end of the header is to scan forward. >> >> 2. Alignment sensitivity! Because there is no header length >> information, the above scan tells you where the header ends, but >there >> is padding before the data, and the size of that padding is only >defined >> by alignment. >> >> 3. Inband encoding of EOF: if you actually have a filename >"TRAILER!!!" >> you have problems. >> >> But first, before you define a whole new format for which no tools >exist >> (you will have to work with the maintainers of the GNU tools to add >> support) you should see how complex it would be to support the POSIX >> tar/pax format, which already has all the features you are seeking, >and >> by now is well-supported. > >The discussion about including xattrs in the initramfs didn't start >yesterday. It's been on the list of measurement/appraisal gaps that >need to be closed for years. Initially I planned on using tar, but at >the 2014 Kernel Summit I spoke with Al at length. At the time, he was >very clear that tar is unnecessarily overly complicated and >recommended extending CPIO. > >I took his advice. Unfortunately, as soon as I posted an initial >patch set to include xattrs in CPIO, all of the problems with CPIO had >to be addressed before defining a new CPIO number. Unfortunately, >this wasn't the only measurement/appraisal gap that needed to be >addressed. I've been working on closing other gaps. > >I'm really happy that someone has taken the time to work on this. > Instead of derailing their attempt of extending CPIO to include >xattrs, I'd appreciate your making constructive suggestions. > >Mimi I'm not trying to derail anything, but I do want to see it done well if it is going to be done. I have several ideas already, but I may not have a chance to write them down properly until after the weekend due to family obligations. The assessment of pax/tar is useful; it should be added to the patch documentation in a future set. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Project
Hi, Compliment of the day. My name is Brian Abrahart, I work with ExxonMobil as a project manager here in Leatherhead, UK. I have an important business transaction I will like to share with you. Do find it proper to contact me for more details. Thank you. Best Regards, Engr. Brian Abrahart
Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description
On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote: > On 02/16/18 12:33, Taras Kondratiuk wrote: > > Many of the Linux security/integrity features are dependent on file > > metadata, stored as extended attributes (xattrs), for making decisions. > > These features need to be initialized during initcall and enabled as > > early as possible for complete security coverage. > > > > Initramfs (tmpfs) supports xattrs, but newc CPIO archive format does not > > support including them into the archive. > > > > This patch describes "extended" newc format (newcx) that is based on > > newc and has following changes: > > - extended attributes support > > - increased size of filesize to support files >4GB > > - increased mtime field size to have 64 bits of seconds and added a > > field for nanoseconds > > - removed unused checksum field > > > > If you are going to implement a new, non-backwards-compatible format, > you shouldn't replicate the mistakes of the current format. Specifically: > > 1. The use of ASCII-encoded fixed-length numbers is an idiotic legacy > from an era before there were any portable way of dealing with numbers > with prespecified endianness. If you are going to use ASCII, make them > delimited so that they don't have fixed limits, or just use binary. > > The cpio header isn't fixed size, so that argument goes away, in fact > the only way to determine the end of the header is to scan forward. > > 2. Alignment sensitivity! Because there is no header length > information, the above scan tells you where the header ends, but there > is padding before the data, and the size of that padding is only defined > by alignment. > > 3. Inband encoding of EOF: if you actually have a filename "TRAILER!!!" > you have problems. > > But first, before you define a whole new format for which no tools exist > (you will have to work with the maintainers of the GNU tools to add > support) you should see how complex it would be to support the POSIX > tar/pax format, which already has all the features you are seeking, and > by now is well-supported. The discussion about including xattrs in the initramfs didn't start yesterday. It's been on the list of measurement/appraisal gaps that need to be closed for years. Initially I planned on using tar, but at the 2014 Kernel Summit I spoke with Al at length. At the time, he was very clear that tar is unnecessarily overly complicated and recommended extending CPIO. I took his advice. Unfortunately, as soon as I posted an initial patch set to include xattrs in CPIO, all of the problems with CPIO had to be addressed before defining a new CPIO number. Unfortunately, this wasn't the only measurement/appraisal gap that needed to be addressed. I've been working on closing other gaps. I'm really happy that someone has taken the time to work on this. Instead of derailing their attempt of extending CPIO to include xattrs, I'd appreciate your making constructive suggestions. Mimi
Re: [PATCH 3/3] ARM: dts: stm32: Add display support on stm32f469-disco
Hi Philippe, Thank you for the patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on v4.16-rc1 next-20180216] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Philippe-Cornu/ARM-dts-stm32-Add-display-support-on-stm32f469-disco/20180218-052546 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: arm-at91_dt_defconfig (attached as .config) compiler: arm-linux-gnueabi-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=arm All errors (new ones prefixed by >>): >> Error: arch/arm/boot/dts/stm32f469.dtsi:14.21-22 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v3 1/1] mm: page_alloc: skip over regions of invalid pfns on UMA
Hello Andrew, On Fri, Feb 16, 2018 at 04:43:28PM -0800, Andrew Morton wrote: > On Mon, 12 Feb 2018 19:47:59 +0100 Michal Hocko wrote: > > > > prerequisite for this is to reach some agreement on what people think is > > > the best option, which I feel didn't occur yet. > > > > I do not have a _strong_ preference here as well. So I will leave the > > decision to you. > > > > In any case feel free to add > > Acked-by: Michal Hocko > > I find Michal's version to be a little tidier. > > Eugeniu, please send Michal's patch at me with a fresh changelog, with > your signed-off-by and your tested-by and your reported-by and we may > as well add Michal's (thus-far-missing) signed-off-by ;) I only needed to apply below touch to Michal's patch, which otherwise works fine for me. I've sent it to you as v4. Thank you very much for picking it. Best regards, Eugeniu. diff --git a/mm/page_alloc.c b/mm/page_alloc.c index cb3f844092ad..66891b3fb144 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5356,7 +5356,7 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, * end_pfn), such that we hit a valid pfn (or end_pfn) * on our next iteration of the loop. */ - if IS_ENABLED(HAVE_MEMBLOCK) + if (IS_ENABLED(CONFIG_HAVE_MEMBLOCK)) pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1; continue; }
Re: What was last kernel that booted on hardware XY? database was Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2A
On Sat, Feb 17, 2018 at 4:16 PM, Pavel Machek wrote: > Hi! > >> > BTW... I'd really like to have a database of machine, kernel version, >> > cpuinfo, config... So that questions like "what is the latest kernel >> > that is known to be running on this hardware" and "what config should >> > I start from". >> > >> > For example, I have nokia N810 here. It was supported by Linux at some >> > point, but then we moved to dts, and stuff changed, and I can no >> > longer figure how to boot it. >> > >> > I guess "what was last kernel that worked on Cyrix MII" is also >> > relevant question. >> > >> > Is there such database? If not, would people be interested in >> > contributing if I create one? >> > >> >> I am interested and will help. I have i486/i586/Pentium Pro/Pentium >> II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet >> have Pentium III systems. >> >> I think an associated goal would be to fix those broken versions. >> >> I think this is a great project for college students to get experience >> with. Who else is interested? > > Ok, I started something: > > https://github.com/pavelmachek/missy > This is a good start. Could we start to create a hierarchy of major architectures next? I propose the following: i486->Intel->i486 i486->Cyrix->Cx486 i486->AMD->Am486 i486->UMC->Green CPU i586->Intel->Pentium Classic i586->Intel->Pentium MMX i586->Intel->Atom i586->AMD->K5 i586->AMD->K6 i586->AMD->K6 II i586->AMD->K6 III i586->Cyrix->5x86 i586->Cyrix->6x86 i586->Cyrix->6x86MX i586->Cyrix->Cyrix III i686->Intel->Pentium Pro i686->Intel->Pentium II i686->Intel->Pentium III i686->Intel->Pentium 4 i686->Intel->Pentium M i686->Intel->Core 2 i686->AMD->K7 i686->AMD->K8 You would put the computer you tested it on inside one of these directories. This will need to be edited if you choose to use it. I left out items I know little about, such as Geode GX1, Geode LX, VIA C3-2, VIA C7, Transmeta Crusoe and Efficeon, Winchip-2, Winchip-C6, and certainly others. - Matthew
Re: BUG: sleeping function called from invalid context at net/core/sock.c:LINE (3)
On 17.02.2018 11:15, Dmitry Vyukov wrote: > On Sat, Feb 17, 2018 at 4:00 AM, syzbot > wrote: >> Hello, >> >> syzbot hit the following crash on net-next commit >> 65bd449c32c2745df61913ab54087e77f9d9b70d (Fri Feb 16 20:26:35 2018 +) >> Merge branch 'tipc-de-generealize-topology-server' > > +tipc maintainers This looks to be caused by commit 0ef897be12b8 "tipc: separate topology server listener socket from subcsriber sockets" Thanks, Kirill
Re: [PATCH] p9caps: add Plan9 capability devices
On Sun, Feb 11, 2018 at 10:50 PM, Enrico Weigelt, metux IT consult
wrote:
> From: "Enrico Weigelt, metux IT consult"
>
> This driver implements the Plan9 capability devices, used for
> switching user id via capability tokens.
>
> https://9p.io/sys/doc/auth.html
Please see some nit-picks below.
I'm still reading the plan9 docs to fully get the big picture.
> ---
> drivers/staging/Kconfig | 2 +
> drivers/staging/Makefile| 1 +
> drivers/staging/p9caps/Kconfig | 11 ++
> drivers/staging/p9caps/Makefile | 1 +
> drivers/staging/p9caps/p9caps.c | 369
>
> 5 files changed, 384 insertions(+)
> create mode 100644 drivers/staging/p9caps/Kconfig
> create mode 100644 drivers/staging/p9caps/Makefile
> create mode 100644 drivers/staging/p9caps/p9caps.c
>
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index 554683912cff..23f325339fe8 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -118,4 +118,6 @@ source "drivers/staging/vboxvideo/Kconfig"
>
> source "drivers/staging/pi433/Kconfig"
>
> +source "drivers/staging/p9caps/Kconfig"
> +
> endif # STAGING
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index 6e536020029a..eccdf4643453 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -3,6 +3,7 @@
>
> obj-y += media/
> obj-y += typec/
> +obj-$(CONFIG_PLAN9CAPS)+= p9caps/
> obj-$(CONFIG_IRDA) += irda/net/
> obj-$(CONFIG_IRDA) += irda/drivers/
> obj-$(CONFIG_PRISM2_USB) += wlan-ng/
> diff --git a/drivers/staging/p9caps/Kconfig b/drivers/staging/p9caps/Kconfig
> new file mode 100644
> index ..b909daaa79ce
> --- /dev/null
> +++ b/drivers/staging/p9caps/Kconfig
> @@ -0,0 +1,11 @@
> +config PLAN9CAPS
> + tristate "Plan 9 capability device"
> + default n
> + select CRYPTO_HMAC
> + select CRYPTO_SHA1
> + help
> + This module implements the Plan 9 capability devices
> + /dev/caphash and /dev/capuse
> +
> + To compile this driver as a module, choose
> + M here: the module will be called p9caps.
> diff --git a/drivers/staging/p9caps/Makefile b/drivers/staging/p9caps/Makefile
> new file mode 100644
> index ..67d38099a249
> --- /dev/null
> +++ b/drivers/staging/p9caps/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_PLAN9CAPS)+= p9caps.o
> diff --git a/drivers/staging/p9caps/p9caps.c b/drivers/staging/p9caps/p9caps.c
> new file mode 100644
> index ..e46b09821c18
> --- /dev/null
> +++ b/drivers/staging/p9caps/p9caps.c
> @@ -0,0 +1,369 @@
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * Plan9 /dev/caphash and /dev/capuse device
> + *
> + * 2DO: - caphash should only allow one process (per userns)
> + * - support textual user names
> + * - invalidate old caps
> + */
> +
> +#define DEVICE_CAPUSE "/dev/capuse"
> +#define DEVICE_CAPHASH "/dev/caphash"
> +
> +struct caphash_entry {
> + struct list_head list;
> + struct user_namespace *user_ns;
> + char data[SHA1_DIGEST_SIZE];
> +};
> +
> +struct caphash_writer {
> + struct list_head list;
> + struct user_namespace *user_ns;
> +};
> +
> +static dev_t caphash_devid = 0;
> +static dev_t capuse_devid = 0;
Static vars are already 0, no need to initialize them.
> +static LIST_HEAD(caphash_entries);
> +static LIST_HEAD(caphash_writers);
> +
> +static DEFINE_MUTEX(lock);
> +
> +struct crypto_ahash *hmac_tfm = NULL;
> +
> +static int caphash_open(struct inode *inode, struct file *filp)
> +{
> + struct caphash_writer *tmp = NULL;
> + struct user_namespace *user_ns = current_user_ns();
> + int retval = 0;
> + struct list_head *pos, *q;
> +
> + /* make sure only one instance per namespace can be opened */
> + mutex_lock(&lock);
> +
> + list_for_each_safe(pos, q, &(caphash_writers)) {
> + tmp = list_entry(pos, struct caphash_writer, list);
> + if (tmp->user_ns == user_ns) {
> + pr_err("already locked in this namespace\n");
So, evil guy opens the device but does not close it, therefore the
whole service is blocked in a namespace?
In general, I think we should open that device in
kernel_init_freeable() and hand over the fd to init/systemd.
As the plan9 docs state "The write-only file /dev/caphash can be
opened only by the host owner, and only once. Factotum opens this file
immediately after booting."
> + retval = -EBUSY;
> + goto out;
> + }
> + }
> +
> + if (!(tmp = kzalloc(sizeof(struct caphash_writer), GFP_KERNEL))) {
> + retval = -ENOMEM;
Re: [PATCH] auxdisplay: Replace licenses with SPDX identifiers
2018-02-17 20:39 GMT+01:00 Miguel Ojeda : > Cc: Willy Tarreau > Cc: Geert Uytterhoeven > Cc: Linus Walleij > Cc: Robin van der Gracht > Cc: Paul Burton > Signed-off-by: Miguel Ojeda > --- > Please let me know if you agree for your files and I will queue it up. > Thanks! Acked-by: Linus Walleij Yours, Linus Walleij
i wait your respond
-- Greetings, I wonder why you continue neglecting my emails. Please, acknowledge the receipt of this message in reference to the subject above as I intend to send to you the details of the project. Sometimes, try to check your spam box because most of these correspondences fall out sometimes in SPAM folder. Best regards, Mr. Aziz Ibrahim --
Re: [PATCH 04/10] pinctrl: actions: Add Actions S900 pinctrl driver
Am 17.02.2018 um 21:44 schrieb Manivannan Sadhasivam:
> Add pinctrl driver for Actions Semi S900 SoC. The driver supports
> pinctrl, pinmux and pinconf functionalities through a range of registers
> common to both gpio driver and pinctrl driver.
>
> Pinmux functionality is available only for the pin groups while the
> pinconf functionality is available for both pin groups and individual
> pins.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/pinctrl/Kconfig|1 +
> drivers/pinctrl/Makefile |1 +
> drivers/pinctrl/actions/Kconfig| 12 +
> drivers/pinctrl/actions/Makefile |2 +
> drivers/pinctrl/actions/pinctrl-owl.c | 573
> drivers/pinctrl/actions/pinctrl-owl.h | 178 +++
> drivers/pinctrl/actions/pinctrl-s900.c | 2536
>
> 7 files changed, 3303 insertions(+)
> create mode 100644 drivers/pinctrl/actions/Kconfig
> create mode 100644 drivers/pinctrl/actions/Makefile
> create mode 100644 drivers/pinctrl/actions/pinctrl-owl.c
> create mode 100644 drivers/pinctrl/actions/pinctrl-owl.h
> create mode 100644 drivers/pinctrl/actions/pinctrl-s900.c
>
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 0f254b35c378..838c8fff8c24 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -368,6 +368,7 @@ config PINCTRL_OCELOT
> select GENERIC_PINMUX_FUNCTIONS
> select REGMAP_MMIO
>
> +source "drivers/pinctrl/actions/Kconfig"
> source "drivers/pinctrl/aspeed/Kconfig"
> source "drivers/pinctrl/bcm/Kconfig"
> source "drivers/pinctrl/berlin/Kconfig"
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index d3692633e9ed..bf41d2484a44 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_PINCTRL_INGENIC) += pinctrl-ingenic.o
> obj-$(CONFIG_PINCTRL_RK805) += pinctrl-rk805.o
> obj-$(CONFIG_PINCTRL_OCELOT) += pinctrl-ocelot.o
>
> +obj-$(CONFIG_ARCH_ACTIONS) += actions/
Here you require CONFIG_ARCH_ACTIONS ...
> obj-$(CONFIG_ARCH_ASPEED)+= aspeed/
> obj-y+= bcm/
> obj-$(CONFIG_PINCTRL_BERLIN) += berlin/
> diff --git a/drivers/pinctrl/actions/Kconfig b/drivers/pinctrl/actions/Kconfig
> new file mode 100644
> index ..6075909d04e9
> --- /dev/null
> +++ b/drivers/pinctrl/actions/Kconfig
> @@ -0,0 +1,12 @@
> +config PINCTRL_OWL
> +bool
Indentation.
> + depends on (ARCH_ACTIONS || COMPILE_TEST) && OF
... so || COMPILE_TEST becomes moot.
Use CONFIG_PINCTRL_OWL in Makefile instead?
> + select PINMUX
> + select PINCONF
> + select GENERIC_PINCONF
> +
> +config PINCTRL_S900
> + bool "Actions Semi S900 pinctrl driver"
> + select PINCTRL_OWL
> + help
> + Say Y here to enable Actions S900 pinctrl driver
Repeating the shortened name does not seem too helpful?
> diff --git a/drivers/pinctrl/actions/Makefile
> b/drivers/pinctrl/actions/Makefile
> new file mode 100644
> index ..bd232d28400f
> --- /dev/null
> +++ b/drivers/pinctrl/actions/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_PINCTRL_OWL)+= pinctrl-owl.o
> +obj-$(CONFIG_PINCTRL_S900) += pinctrl-s900.o
> diff --git a/drivers/pinctrl/actions/pinctrl-owl.c
> b/drivers/pinctrl/actions/pinctrl-owl.c
> new file mode 100644
> index ..7ed8625c30f3
> --- /dev/null
> +++ b/drivers/pinctrl/actions/pinctrl-owl.c
> @@ -0,0 +1,573 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * OWL SoC's Pinctrl driver
> + *
> + * Copyright (c) 2014 Actions Semi Inc.
> + * Author: David Liu
> + *
> + * Copyright (c) 2018 Linaro Ltd.
> + * Author: Manivannan Sadhasivam
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../core.h"
> +#include "../pinctrl-utils.h"
> +#include "pinctrl-owl.h"
> +
> +/**
> + * struct owl_pinctrl - pinctrl state of the device
> + * @dev: device handle
> + * @pctrldev: pinctrl handle
> + * @lock: spinlock to protect registers
> + * @soc: reference to soc_data
> + * @base: pinctrl register base address
> + */
> +struct owl_pinctrl {
> + struct device *dev;
> + struct pinctrl_dev *pctrldev;
> + raw_spinlock_t lock;
> + struct clk *clk;
> + const struct owl_pinctrl_soc_data *soc;
> + void __iomem *base;
> +};
> +
> +static int owl_get_groups_count(struct pinctrl_dev *pctrldev)
> +{
> + struct owl_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrldev);
> +
> + return pctrl->soc->ngroups;
> +}
> +
> +static const char *owl_get_group_name(struct pinctrl_dev *pctrldev,
> + unsigned int group)
> +{
> + struct owl_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrldev);
> +
> + return pctrl->soc->groups[group].name;
> +}
> +
> +static int owl_get_group_pins(struct pinctrl_dev *pctrldev,
> +
Re: [PATCH] auxdisplay: Replace licenses with SPDX identifiers
On Sat, Feb 17, 2018 at 08:39:55PM +0100, Miguel Ojeda wrote: > Cc: Willy Tarreau > Cc: Geert Uytterhoeven > Cc: Linus Walleij > Cc: Robin van der Gracht > Cc: Paul Burton > Signed-off-by: Miguel Ojeda > --- > Please let me know if you agree for your files and I will queue it up. > Thanks! Ack from me. Willy
Re: [PATCH 10/10] MAINTAINERS: Add Actions Semi S900 pinctrl and gpio entries
Am 17.02.2018 um 21:44 schrieb Manivannan Sadhasivam: > Add S900 pinctrl and gpio entries under ARCH_ACTIONS > > Signed-off-by: Manivannan Sadhasivam > --- > MAINTAINERS | 4 > 1 file changed, 4 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 96b8b6531196..b718be5af680 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1126,11 +1126,15 @@ F:arch/arm/boot/dts/owl-* > F: arch/arm64/boot/dts/actions/ > F: drivers/clocksource/owl-* > F: drivers/soc/actions/ > +F: drivers/pinctrl/actions/* > +F: drivers/gpio/gpio-owl.c > F: include/dt-bindings/power/owl-* > F: include/linux/soc/actions/ > F: Documentation/devicetree/bindings/arm/actions.txt > F: Documentation/devicetree/bindings/power/actions,owl-sps.txt > F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt > +F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt > +F: Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt Please retain alphabetical ordering. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 00/10] Add Actions Semi S900 pinctrl and gpio support
Am 17.02.2018 um 21:44 schrieb Manivannan Sadhasivam: > This patchset adds pinctrl and gpio support for Actions Semi S900 SoC. > Pinctrl and gpio subsystems share the common set of register range but > implemented as individual drivers for making it less complex. > > Pinmux functions are only accessible for pin groups while pinconf > parameters are available for both pin groups and individual pins. > > gpio-line-names has been added for the Bubblegum-96 board matching the > 96Boards CE specification v1.0. > > Both pinctrl and gpio drivers are verified using the Bubblegum-96 board. > > This patchset depends on the clock driver which is still under review: > https://lkml.org/lkml/2018/2/9/831 What this forgets to point out is that I had authored pinctrl and gpio drivers for S500, with preparations for S700 and S900, derived from my to-be-submitted pinctrl/gpio drivers for RTD1295, while this one was developed independently by Mani for S900. Our intention is to align them as part of patch review and redo S500 on top of the result. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [RFC PATCH] input: Add disable sysfs entry for every input device
Hi! > > > > So, do you mean to implement this "disable" action as ioctl for > > > > particular /dev/input/event* device (instead of sysfs entry)? > > > > > > Yes, so the device can be powered down without the device node being > > > closed and made unavailable. I don't know whether that's something > > > that's already possible for all cases, but there's already > > > opportunistic in a lot of drivers and subsystems. > > > > > > This opens up a whole new wave of potential problems, but it's a more > > > generally useful mechanism, I would think. > > > > Ok. How should API for this ioctl looks like? And do you have an idea > > for name of that ioctl? > > > > Dmitry, what do you think about it? It is acceptable for you? > > first: sysfs files are pretty terrible because writing to them requires root > and we don't have the benefit of logind. so for any sysfs toggle expect > a nicely integrated userspace solution to be less than optimal. Well, you can chmod / chown sysfs files. > besides: 99% of the above is figuring out the policy *when* to disable the > device. disabling it is trivial by just closing the evdev nodes and tbh I > don't think we (in userspace) should care about whether the device is > powered down or now, it should be the default assumption that it is powered > down when not in use. > > for the cases where you must keep the device open but you don't want events, > EVIOCSMASK is likely the best solution. improving the kernel so it powers > down the device when the mask excludes all events (and there are no other > listeners) could be an interesting task. But yes, that sounds like an idea. BTW in the meantime, someone added this to pmos wiki... this should solve some of my problems. Best regards, Pavel FILE=~/.screenoff if [ -f $FILE ]; then xinput set-prop 8 "Device Enabled" 1 xinput set-prop 6 "Device Enabled" 1 xinput set-prop 9 "Device Enabled" 1 xset dpms force on rm ~/.screenoff else xinput set-prop 8 "Device Enabled" 0 xinput set-prop 6 "Device Enabled" 0 xinput set-prop 9 "Device Enabled" 0 xset dpms force off touch ~/.screenoff fi -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
setterm -blank force no longer works after switch to omapdrm
Hi! I used to have use omap fb driver, and blanking worked as expected. It no longer works with omap drm driver. (Tested on v4.16-rc1, but I believe it is broken in older versions, too.) Can you test it on your hw? Any ideas what could be wrong? xset dpms force on/off works as expected. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: What was last kernel that booted on hardware XY? database was Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2A
Hi! > > BTW... I'd really like to have a database of machine, kernel version, > > cpuinfo, config... So that questions like "what is the latest kernel > > that is known to be running on this hardware" and "what config should > > I start from". > > > > For example, I have nokia N810 here. It was supported by Linux at some > > point, but then we moved to dts, and stuff changed, and I can no > > longer figure how to boot it. > > > > I guess "what was last kernel that worked on Cyrix MII" is also > > relevant question. > > > > Is there such database? If not, would people be interested in > > contributing if I create one? > > > > I am interested and will help. I have i486/i586/Pentium Pro/Pentium > II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet > have Pentium III systems. > > I think an associated goal would be to fix those broken versions. > > I think this is a great project for college students to get experience > with. Who else is interested? Ok, I started something: https://github.com/pavelmachek/missy I try to test -rc1 and final versions on thinkpads X60 and X220. (I'd like to do testing of even -next from time to time.) I do have T40p and test maybe every other version on that one. I test Nokia N900 quite often (including next), and plan to test N9/N950 too. Of course, more "exotic" hardware would be welcome. I did have linux on sun4/330, unfortunately I don't think I have access to that any more. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 06/10] arm64: dts: actions: Add S900 gpio nodes
Am 17.02.2018 um 21:44 schrieb Manivannan Sadhasivam:
> Add gpio nodes for Actions Semi S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm64/boot/dts/actions/s900.dtsi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
> b/arch/arm64/boot/dts/actions/s900.dtsi
> index 0156483f0f4d..e359509ad9d3 100644
> --- a/arch/arm64/boot/dts/actions/s900.dtsi
> +++ b/arch/arm64/boot/dts/actions/s900.dtsi
> @@ -180,6 +180,13 @@
> clocks = <&cmu CLK_GPIO>;
> };
>
> + gpio: gpio@e01b {
> + compatible = "actions,s900-gpio";
> + reg = <0x0 0xe01b 0x0 0x1000>;
> + gpio-controller;
Same as the bindings example, this is lacking gpio-ranges.
https://github.com/afaerber/linux/commit/f4526bbacd75d014a69e6e3ff051638589ee71a3
Also why have only one node? That forces the information about GPIO
banks into the driver rather than into the DT.
> + #gpio-cells = <2>;
> + };
> +
> timer: timer@e0228000 {
> compatible = "actions,s900-timer";
> reg = <0x0 0xe0228000 0x0 0x8000>;
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
[PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4
Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
It is used on some Motorola Mapphone series of phones and tablets such
as Droid 4.
The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
device it seems. We know this as we get L3 errors from omap-usb-host if
trying to use the PHY before MDM6600 is configured.
The GPIOs controlling MDM6600 are used to power MDM660 on and off, to
configure the USB start-up mode (normal mode versus USB flashing), and
they also tell the state of the MDM6600 device.
The two start-up mode GPIOs are dual-purposed and used for out of band
(OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
the USB start-up mode first to get MDM6600 booted in the right mode to
be usable in the first place.
For now, this driver just gives up the two start-up mode GPIOs after the
modem has been configured to boot in normal mode. One of them we may
want to configure for USB OOB wake in this driver later on, but that's a
separate series of patches and needs more work.
Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
driver for modems. But it really does not control the radio at all, it
just controls the modem power and start-up mode for USB. So I came to
the conclusion that we're better off having this done in the USB PHY
driver. For adding support for USB flashing mode, we can later on add
a kernel module option for flash_mode=1 or something similar.
Also note that currently there is no PM runtime support for the OHCI
on omap variant SoCs. So for low(er) power idle states, currenty both
ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.
For reference here is what I measured for total power consumption on
an idle Droid 4 with and without USB related MDM6600 modules:
idle lcd offphy-mapphone-mdm6600ohci-platform
153mW 284mW 344mW
So it seems that MDM6600 is currently not yet idling even with it's
radio turned off, but that's something that is beyond the control of
this USB PHY driver.
Cc: devicet...@vger.kernel.org
Cc: Mark Rutland
Cc: Marcel Partap
Cc: Michael Scott
Cc: Rob Herring
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
.../bindings/phy/phy-mapphone-mdm6600.txt | 30 ++
drivers/phy/motorola/Kconfig | 9 +
drivers/phy/motorola/Makefile | 1 +
drivers/phy/motorola/phy-mapphone-mdm6600.c| 490 +
4 files changed, 530 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c
diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
@@ -0,0 +1,30 @@
+Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
+
+Required properties:
+- compatible Must be "motorola,mapphone-mdm6600"
+- enable-gpios GPIO to enable the USB PHY
+- power-gpios GPIO to power on the device
+- reset-gpios GPIO to reset the device
+- mode-gpios Two GPIOs to configure MDM6600 USB start-up mode for
+ normal mode versus USB flashing mode
+- status-gpios Three GPIOs to read the power state of the MDM6600
+- cmd-gpiosThree GPIOs to control the power state of the MDM6600
+
+Example:
+
+fsusb1_phy: fsusb1_phy {
+ compatible = "motorola,mapphone-mdm6600";
+ enable-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>; /* gpio_95 */
+ power-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>; /* gpio_54 */
+ reset-gpios = <&gpio2 17 GPIO_ACTIVE_HIGH>; /* gpio_49 */
+ mode-gpios = <&gpio5 20 GPIO_ACTIVE_HIGH>, /* gpio_148 */
+<&gpio5 21 GPIO_ACTIVE_HIGH>; /* gpio_149 */
+ status-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>,/* gpio_55 */
+ <&gpio2 21 GPIO_ACTIVE_HIGH>,/* gpio_53 */
+ <&gpio2 20 GPIO_ACTIVE_HIGH>;/* gpio_52 */
+ cmd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>,/* gpio_103 */
+ <&gpio4 8 GPIO_ACTIVE_HIGH>,/* gpio_104 */
+ <&gpio5 14 GPIO_ACTIVE_HIGH>; /* gpio_142 */
+ #phy-cells = <0>;
+};
+
diff --git a/drivers/phy/motorola/Kconfig b/drivers/phy/motorola/Kconfig
--- a/drivers/phy/motorola/Kconfig
+++ b/drivers/phy/motorola/Kconfig
@@ -10,3 +10,12 @@ config PHY_CPCAP_USB
help
Enable this for USB to work on Motorola phones and tablets
such as Droid 4.
+
+config PHY_MAPPHONE_MDM6600
+ tristate "Motorola Mapphone MDM6600 modem USB PHY driver"
+ depends on USB_SUPPORT
+ select GENERIC_PHY
+ select USB_PHY
+ help
+ Enable this for MDM6600 USB modem to work on Motorola phones
+
Re: [PATCH 01/10] dt-bindings: pinctrl: Add bindings for Actions S900 SoC
Am 17.02.2018 um 21:44 schrieb Manivannan Sadhasivam: > Add pinctrl bindings for Actions Semi S900 SoC > > Signed-off-by: Manivannan Sadhasivam > --- > .../bindings/pinctrl/actions,s900-pinctrl.txt | 171 > + > 1 file changed, 171 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt > > diff --git > a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt > b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt > new file mode 100644 > index ..ee7d3ecd9bd9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt > @@ -0,0 +1,171 @@ > +Actions Semi S900 Pin Controller So you are targeting to have one bindings file per SoC? > + > +This binding describes the pin controller found in the S900 SoC. > + > +Required Properties: > + > +- compatible: Should be "actions,s900-pinctrl" > +- reg: Should contain the register base address and size of > +the pin controller. > +- clocks: phandle of the clock feeding the pin controller > + > +Please refer to pinctrl-bindings.txt in this directory for details of the > +common pinctrl bindings used by client devices, including the meaning of the > +phrase "pin configuration node". > + > +The pin configuration nodes act as a container for an arbitrary number of > +subnodes. Each of these subnodes represents some desired configuration for a > +pin, a group, or a list of pins or groups. This configuration can include the > +mux function to select on those group(s), and various pin configuration > +parameters, such as pull-up, drive strength, etc. > + > +PIN CONFIGURATION NODES: > + > +The name of each subnode is not important; all subnodes should be enumerated > +and processed purely based on their content. > + > +Each subnode only affects those parameters that are explicitly listed. In > +other words, a subnode that lists a mux function but no pin configuration > +parameters implies no information about any pin configuration parameters. > +Similarly, a pin subnode that describes a pullup parameter implies no > +information about e.g. the mux function. > + > +Pinmux functions are available only for the pin groups while pinconf > +parameters are available for both pin groups and individual pins. > + > +The following generic properties as defined in pinctrl-bindings.txt are valid > +to specify in a pin configuration subnode: > + > +Required Properties: > + > +- pins: An array of strings, each string containing the name of a > pin. > + These pins are used for selecting the pull control and > schmitt > + trigger parameters. The following are the list of pins > + available: > + > + ETH_TXD0, ETH_TXD1, ETH_TXEN, ETH_RXER, ETH_CRS_DV, > + ETH_RXD1, ETH_RXD0, ETH_REF_CLK, ETH_MDC, ETH_MDIO, > + SIRQ0, SIRQ1, SIRQ2, I2S_D0, I2S_BCLK0, I2S_LRCLK0, > + I2S_MCLK0, I2S_D1, I2S_BCLK1, I2S_LRCLK1, I2S_MCLK1, > + PCM1_IN, PCM1_CLK, PCM1_SYNC, PCM1_OUT, ERAM_A5, > + ERAM_A6, ERAM_A7, ERAM_A8, ERAM_A9, ERAM_A10, ERAM_A11, > + LVDS_OEP, LVDS_OEN, LVDS_ODP, LVDS_ODN, LVDS_OCP, > + LVDS_OCN, LVDS_OBP, LVDS_OBN, LVDS_OAP, LVDS_OAN, > + LVDS_EEP, LVDS_EEN, LVDS_EDP, LVDS_EDN, LVDS_ECP, > + LVDS_ECN, LVDS_EBP, LVDS_EBN, LVDS_EAP, LVDS_EAN, > + SD0_D0, SD0_D1, SD0_D2, SD0_D3, SD1_D0, SD1_D1, > + SD1_D2, SD1_D3, SD0_CMD, SD0_CLK, SD1_CMD, SD1_CLK, > + SPI0_SCLK, SPI0_SS, SPI0_MISO, SPI0_MOSI, UART0_RX, > + UART0_TX, UART2_RX, UART2_TX, UART2_RTSB, UART2_CTSB, > + UART3_RX, UART3_TX, UART3_RTSB, UART3_CTSB, UART4_RX, > + UART4_TX, I2C0_SCLK, I2C0_SDATA, I2C1_SCLK, I2C1_SDATA, > + I2C2_SCLK, I2C2_SDATA, CSI0_DN0, CSI0_DP0, CSI0_DN1, > + CSI0_DP1, CSI0_CN, CSI0_CP, CSI0_DN2, CSI0_DP2, CSI0_DN3, > + CSI0_DP3, DSI_DP3, DSI_DN3, DSI_DP1, DSI_DN1, DSI_CP, > + DSI_CN, DSI_DP0, DSI_DN0, DSI_DP2, DSI_DN2, SENSOR0_PCLK, > + CSI1_DN0,CSI1_DP0,CSI1_DN1, CSI1_DP1, CSI1_CN, CSI1_CP, > + SENSOR0_CKOUT, NAND0_D0, NAND0_D1, NAND0_D2, NAND0_D3, > + NAND0_D4, NAND0_D5, NAND0_D6, NAND0_D7, NAND0_DQS, > + NAND0_DQSN, NAND0_ALE, NAND0_CLE, NAND0_CEB0, NAND0_CEB1, > + NAND0_CEB2, NAND0_CEB3, NAND1_D0, NAND1_D1, NAND1_D2, > + NAND1_D3, NAND1_D4, NAND1_D5, NAND1_D6, NAND1_D7, > NAND1_DQS, > + NAND1_DQSN, NAND1_ALE, NAND1_CLE, NAND1_CEB0, NAND1_CEB1, > + NAND1_CEB2, NAND1_CEB3, SGPIO0, SGPIO1, SGPIO2, SGPIO3 Should be lower-case? > + > +- groups: An array of strings, each string containing the name of a
Re: [PATCH v2] md-multipath: Use seq_putc() in multipath_status()
On Sat, Jan 13, 2018 at 09:55:08AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 13 Jan 2018 09:49:03 +0100 > > A single character (closing square bracket) should be put into a sequence. > Thus use the corresponding function "seq_putc". > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring applied, thanks > --- > drivers/md/md-multipath.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/md/md-multipath.c b/drivers/md/md-multipath.c > index e40065bdbfc8..0a7e99d62c69 100644 > --- a/drivers/md/md-multipath.c > +++ b/drivers/md/md-multipath.c > @@ -157,7 +157,7 @@ static void multipath_status(struct seq_file *seq, struct > mddev *mddev) > seq_printf (seq, "%s", rdev && test_bit(In_sync, &rdev->flags) > ? "U" : "_"); > } > rcu_read_unlock(); > - seq_printf (seq, "]"); > + seq_putc(seq, ']'); > } > > static int multipath_congested(struct mddev *mddev, int bits) > -- > 2.15.1 >
Re: [PATCH] md/raid1: Fix trailing semicolon
On Wed, Jan 17, 2018 at 01:38:02PM +, Luis de Bethencourt wrote: > The trailing semicolon is an empty statement that does no operation. > Removing it since it doesn't do anything. > > Signed-off-by: Luis de Bethencourt > --- > > Hi, > > After fixing the same thing in drivers/staging/rtl8723bs/, Joe Perches > suggested I fix it treewide [0]. applied, thanks! > > Best regards, > Luis > > > [0] > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115410.html > [1] > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115390.html > > drivers/md/raid1.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c > index b2eae332e1a2..f978eddc7a21 100644 > --- a/drivers/md/raid1.c > +++ b/drivers/md/raid1.c > @@ -1108,7 +1108,7 @@ static void alloc_behind_master_bio(struct r1bio > *r1_bio, > > bio_copy_data(behind_bio, bio); > skip_copy: > - r1_bio->behind_master_bio = behind_bio;; > + r1_bio->behind_master_bio = behind_bio; > set_bit(R1BIO_BehindIO, &r1_bio->state); > > return; > -- > 2.15.1 >
Re: i2c-designware: sound and s2ram broken on Broadwell-U system since commit ca382f5b38f367b6 (add i2c gpio recovery option)
On Sat, 2018-02-17 at 17:58 +0100, Dominik Brodowski wrote: > On Sat, Feb 17, 2018 at 05:09:40PM +0200, Andy Shevchenko wrote: > This patch fixes the issue, thanks. I will send it soon out. > Do you still need the DEBUG_GPIO output? It would be nice to have, though if it makes difficulties to you, then don't bother. -- Andy Shevchenko Intel Finland Oy
Re: [v3,07/11] watchdog/hpwdt: Modify to use watchdog core.
On Sat, Feb 17, 2018 at 08:49:07AM -0800, Guenter Roeck wrote:
> On Thu, Feb 15, 2018 at 04:43:56PM -0700, Jerry Hoemann wrote:
> > Follow Documentation/watchdog/convert_drivers_to_kernel_api.txt to
> > convert hpwdt from legacy watchdog driver to use the watchdog core.
> >
> > Removed functions: hpwdt_open, hpwdt_release, hpwdt_write, hpwdt_ioctl
> > Removed data structures: hpwdt_fops, hpwdt_miscdev, watchdog_device
> > Modified functions: hpwdt_start, hpwdt_stop, hpwdt_ping, hpwdt_gettimeleft
> > Added functions: hpwdt_settimeout
> > Added structures: watchdog_device
> >
> > Signed-off-by: Jerry Hoemann
> > ---
> > drivers/watchdog/hpwdt.c | 249
> > ---
> > 1 file changed, 63 insertions(+), 186 deletions(-)
> >
> > diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> > index 71e49d0ab789..da9a04101814 100644
> > --- a/drivers/watchdog/hpwdt.c
> > +++ b/drivers/watchdog/hpwdt.c
> > @@ -14,18 +14,13 @@
> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> > #include
> > -#include
> > -#include
>
> The driver still performs direct IO. Why do you remove this
> include file ?
I was just removing file includes no longer needed to compile
the module. While there are sential ifdef protecting against
compile errors for multiply including the same file, the extra
open and parsing of the file does add a little bit of overhead
to the build time. Probably not as important today as it used
to be.
I will redact the change.
>
> > -#include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > -#include
>
> The PCI vendor IDs used by the driver are declared in this file.
> Is there a direction somewhere suggesting that this file
> should not be directly included ?
See above.
>
> > #include
> > -#include
> > #include
> > +
> > #include
> >
> > #define HPWDT_VERSION "1.4.0"
> > @@ -40,8 +35,6 @@ static bool nowayout = WATCHDOG_NOWAYOUT;
> > #ifdef CONFIG_HPWDT_NMI_DECODING
> > static unsigned int allow_kdump = 1;
> > #endif
> > -static char expect_release;
> > -static unsigned long hpwdt_is_open;
> >
> > static void __iomem *pci_mem_addr; /* the PCI-memory address */
> > static unsigned long __iomem *hpwdt_nmistat;
> > @@ -55,53 +48,58 @@ static const struct pci_device_id hpwdt_devices[] = {
> > };
> > MODULE_DEVICE_TABLE(pci, hpwdt_devices);
> >
> > +static struct watchdog_device hpwdt_dev;
>
> Please no double declarations. This is only needed for the NMI
> code to pass to hpwdt_stop where it isn't used. It would be
> easy to introduce _hpwdt_stop() with no parameter and call that
> function frm hpwdt_stop().
I'll redact this change.
I'll add a new function hpwdt_stop_new (or something like that) which
takes the watchdog_devices as input and it will call current upstream
hpwdt_stop.
>
> >
> > - retval = misc_register(&hpwdt_miscdev);
> > + hpwdt_dev.parent = &dev->dev;
> > + retval = watchdog_register_device(&hpwdt_dev);
> > if (retval < 0) {
> > - dev_warn(&dev->dev,
> > - "Unable to register miscdev on minor=%d (err=%d).\n",
> > - WATCHDOG_MINOR, retval);
> > - goto error_misc_register;
> > + dev_warn(&dev->dev, "Unable to register hpe watchdog
> > (err=%d).\n", retval);
>
> checkpatch warning. Also, this should be dev_err() since it is fatal.
i'll change to dev_err. i'll shorten the message to something similar.
>
> > + goto error_wd_register;
> > }
> >
> > + /* Make sure that timer is disabled until /dev/watchdog is opened */
> > + hpwdt_stop(&hpwdt_dev);
>
> The watchdog is already registered and the device can already have been
> opened at this point. The watchdog would have to be stopped before
> registering the watchdog.
>
> A better approach would be to detect if the watchdog is running and inform
> the watchdog core about it. The code in the stop function suggests that
> this would be possible. This would ensure that the watchdog protection
> during boot is retained.
I will redact this change as it will no longer be necessary. See above.
>
> > +
> > + watchdog_set_nowayout(&hpwdt_dev, nowayout);
> > + if (watchdog_init_timeout(&hpwdt_dev, soft_margin, NULL))
> > + dev_warn(&dev->dev, "Invalid soft_margin: %d. Using default\n",
> > soft_margin);
> > +
> Those two functions should be called before registering the watchdog.
> Also, there is a checkpatch warning.
>
Will change.
Please update the Documentation/watchdog/watchdog-kernel-api.txt.
It is not clear from the documentation which interfaces are to be
called before watchdog_register_device and which ones are to be
called after.
--
-
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-
[PATCH] phy: dm816x-usb: Remove unused phy_data
This is used by some TI USB PHY drivers but not this one, so we can just remove it. Signed-off-by: Tony Lindgren --- drivers/phy/ti/phy-dm816x-usb.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/phy/ti/phy-dm816x-usb.c b/drivers/phy/ti/phy-dm816x-usb.c --- a/drivers/phy/ti/phy-dm816x-usb.c +++ b/drivers/phy/ti/phy-dm816x-usb.c @@ -189,7 +189,6 @@ static int dm816x_usb_phy_probe(struct platform_device *pdev) struct phy_provider *phy_provider; struct usb_otg *otg; const struct of_device_id *of_id; - const struct usb_phy_data *phy_data; int error; of_id = of_match_device(of_match_ptr(dm816x_usb_phy_id_table), @@ -220,8 +219,6 @@ static int dm816x_usb_phy_probe(struct platform_device *pdev) if (phy->usbphy_ctrl == 0x2c) phy->instance = 1; - phy_data = of_id->data; - otg = devm_kzalloc(&pdev->dev, sizeof(*otg), GFP_KERNEL); if (!otg) return -ENOMEM; -- 2.16.1
[PATCH 05/10] dt-bindings: gpio: Add gpio nodes for Actions S900 SoC
Add gpio nodes for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/gpio/actions,owl-gpio.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt
b/Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt
new file mode 100644
index ..4cd4cb7bfd1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt
@@ -0,0 +1,15 @@
+* Actions Semi OWL GPIO controller bindings
+
+- compatible : Should be "actions,s900-gpio"
+- reg : Address and range of the GPIO controller registers.
+- gpio-controller : Marks the device node as a GPIO controller.
+- #gpio-cells : Should be <2>. The first cell is the gpio number and
+the second cell is used to specify optional parameters.
+
+Example:
+ gpio: gpio@e01b {
+ compatible = "actions,s900-gpio";
+ reg = <0x0 0xe01b 0x0 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
--
2.14.1
[PATCH 09/10] MAINTAINERS: Add reviewer for ACTIONS platforms
Since I'll be working on improving support for ACTIONS platforms, adding myself as the reviewer. Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e6c26cb47d02..96b8b6531196 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1117,6 +1117,7 @@ T:git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git ARM/ACTIONS SEMI ARCHITECTURE M: Andreas Färber +R: Manivannan Sadhasivam L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained N: owl -- 2.14.1
[PATCH 08/10] gpio: Add gpio driver for Actions OWL S900 SoC
Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers
controlling the gpio shares the same register range with pinctrl block.
GPIO registers are organized as 6 banks and each bank controls the
maximum of 32 gpios.
Signed-off-by: Manivannan Sadhasivam
---
drivers/gpio/Kconfig| 8 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-owl.c | 258
3 files changed, 267 insertions(+)
create mode 100644 drivers/gpio/gpio-owl.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8dbb2280538d..09ceb98e2434 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -364,6 +364,14 @@ config GPIO_OMAP
help
Say yes here to enable GPIO support for TI OMAP SoCs.
+config GPIO_OWL
+ tristate "Actions OWL GPIO support"
+ default ARCH_ACTIONS
+ depends on ARCH_ACTIONS || COMPILE_TEST
+ depends on OF_GPIO
+ help
+ Say yes here to enable GPIO support for Actions OWL SoCs.
+
config GPIO_PL061
bool "PrimeCell PL061 GPIO support"
depends on ARM_AMBA
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index cccb0d40846c..b2bb11d4675f 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_GPIO_MXC)+= gpio-mxc.o
obj-$(CONFIG_GPIO_MXS) += gpio-mxs.o
obj-$(CONFIG_GPIO_OCTEON) += gpio-octeon.o
obj-$(CONFIG_GPIO_OMAP)+= gpio-omap.o
+obj-$(CONFIG_GPIO_OWL) += gpio-owl.o
obj-$(CONFIG_GPIO_PCA953X) += gpio-pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += gpio-pcf857x.o
obj-$(CONFIG_GPIO_PCH) += gpio-pch.o
diff --git a/drivers/gpio/gpio-owl.c b/drivers/gpio/gpio-owl.c
new file mode 100644
index ..a066c36e8a86
--- /dev/null
+++ b/drivers/gpio/gpio-owl.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// OWL SoC's GPIO driver
+//
+// Copyright (c) 2014 Actions Semi Inc.
+// Author: David Liu
+//
+// Copyright (c) 2018 Linaro Ltd.
+// Author: Manivannan Sadhasivam
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GPIO_OUTEN 0x
+#define GPIO_INEN 0x0004
+#define GPIO_DAT 0x0008
+
+#define OWL_GPIO_PORT_A 0
+#define OWL_GPIO_PORT_B 1
+#define OWL_GPIO_PORT_C 2
+#define OWL_GPIO_PORT_D 3
+#define OWL_GPIO_PORT_E 4
+#define OWL_GPIO_PORT_F 5
+
+struct owl_gpio_port {
+ const char *name;
+ unsigned int offset;
+ unsigned int pins;
+};
+
+struct owl_gpio_soc {
+ const struct owl_gpio_port *ports;
+ unsigned int num_ports;
+ const char *name;
+};
+
+struct owl_gpio {
+ struct gpio_chip gpio;
+ const struct owl_gpio_soc *soc;
+ void __iomem *base;
+};
+
+static void __iomem *owl_gpio_get_base(struct owl_gpio *gpio,
+ unsigned int *pin)
+{
+ unsigned int start = 0, i;
+
+ for (i = 0; i < gpio->soc->num_ports; i++) {
+ const struct owl_gpio_port *port = &gpio->soc->ports[i];
+
+ if (*pin >= start && *pin < start + port->pins) {
+ *pin -= start;
+ return (gpio->base + port->offset);
+ }
+
+ start += port->pins;
+ }
+
+ return NULL;
+}
+
+static int owl_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_gpio *gpio = gpiochip_get_data(chip);
+ void __iomem *gpio_base = owl_gpio_get_base(gpio, &offset);
+ u32 val;
+
+ /*
+* GPIOs have higher priority over other modules, so either setting
+* them as OUT or IN is sufficient
+*/
+ val = readl(gpio_base + GPIO_OUTEN);
+ val |= BIT(offset);
+ writel(val, gpio_base + GPIO_OUTEN);
+
+ return 0;
+}
+
+static void owl_gpio_free(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_gpio *gpio = gpiochip_get_data(chip);
+ void __iomem *gpio_base = owl_gpio_get_base(gpio, &offset);
+ u32 val;
+
+ /* disable gpio output */
+ val = readl(gpio_base + GPIO_OUTEN);
+ val &= ~BIT(offset);
+ writel(val, gpio_base + GPIO_OUTEN);
+
+ /* disable gpio input */
+ val = readl(gpio_base + GPIO_INEN);
+ val &= ~BIT(offset);
+ writel(val, gpio_base + GPIO_INEN);
+}
+
+static int owl_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct owl_gpio *gpio = gpiochip_get_data(chip);
+ void __iomem *gpio_base = owl_gpio_get_base(gpio, &offset);
+ u32 val;
+
+ val = readl(gpio_base + GPIO_DAT);
+
+ return !!(val & BIT(offset));
+}
+
+static void owl_gpio_set(struct gpio_chip *chip, unsigned int offset, int
value)
+{
+ struct owl_gpio *gpio = gpiochip_get_data(chip);
+ void __iomem *gpio_base = owl_gpio_get_base(gpio, &offset);
+ u32 val;
+
+ val = readl(gpio_base + GPIO_DAT);
+
+ if (value)
+
[PATCH 10/10] MAINTAINERS: Add Actions Semi S900 pinctrl and gpio entries
Add S900 pinctrl and gpio entries under ARCH_ACTIONS Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 96b8b6531196..b718be5af680 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1126,11 +1126,15 @@ F: arch/arm/boot/dts/owl-* F: arch/arm64/boot/dts/actions/ F: drivers/clocksource/owl-* F: drivers/soc/actions/ +F: drivers/pinctrl/actions/* +F: drivers/gpio/gpio-owl.c F: include/dt-bindings/power/owl-* F: include/linux/soc/actions/ F: Documentation/devicetree/bindings/arm/actions.txt F: Documentation/devicetree/bindings/power/actions,owl-sps.txt F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt +F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt +F: Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt ARM/ADS SPHERE MACHINE SUPPORT M: Lennert Buytenhek -- 2.14.1
[PATCH 04/10] pinctrl: actions: Add Actions S900 pinctrl driver
Add pinctrl driver for Actions Semi S900 SoC. The driver supports
pinctrl, pinmux and pinconf functionalities through a range of registers
common to both gpio driver and pinctrl driver.
Pinmux functionality is available only for the pin groups while the
pinconf functionality is available for both pin groups and individual
pins.
Signed-off-by: Manivannan Sadhasivam
---
drivers/pinctrl/Kconfig|1 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/actions/Kconfig| 12 +
drivers/pinctrl/actions/Makefile |2 +
drivers/pinctrl/actions/pinctrl-owl.c | 573
drivers/pinctrl/actions/pinctrl-owl.h | 178 +++
drivers/pinctrl/actions/pinctrl-s900.c | 2536
7 files changed, 3303 insertions(+)
create mode 100644 drivers/pinctrl/actions/Kconfig
create mode 100644 drivers/pinctrl/actions/Makefile
create mode 100644 drivers/pinctrl/actions/pinctrl-owl.c
create mode 100644 drivers/pinctrl/actions/pinctrl-owl.h
create mode 100644 drivers/pinctrl/actions/pinctrl-s900.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 0f254b35c378..838c8fff8c24 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -368,6 +368,7 @@ config PINCTRL_OCELOT
select GENERIC_PINMUX_FUNCTIONS
select REGMAP_MMIO
+source "drivers/pinctrl/actions/Kconfig"
source "drivers/pinctrl/aspeed/Kconfig"
source "drivers/pinctrl/bcm/Kconfig"
source "drivers/pinctrl/berlin/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index d3692633e9ed..bf41d2484a44 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_PINCTRL_INGENIC) += pinctrl-ingenic.o
obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
obj-$(CONFIG_PINCTRL_OCELOT) += pinctrl-ocelot.o
+obj-$(CONFIG_ARCH_ACTIONS) += actions/
obj-$(CONFIG_ARCH_ASPEED) += aspeed/
obj-y += bcm/
obj-$(CONFIG_PINCTRL_BERLIN) += berlin/
diff --git a/drivers/pinctrl/actions/Kconfig b/drivers/pinctrl/actions/Kconfig
new file mode 100644
index ..6075909d04e9
--- /dev/null
+++ b/drivers/pinctrl/actions/Kconfig
@@ -0,0 +1,12 @@
+config PINCTRL_OWL
+bool
+ depends on (ARCH_ACTIONS || COMPILE_TEST) && OF
+ select PINMUX
+ select PINCONF
+ select GENERIC_PINCONF
+
+config PINCTRL_S900
+ bool "Actions Semi S900 pinctrl driver"
+ select PINCTRL_OWL
+ help
+ Say Y here to enable Actions S900 pinctrl driver
diff --git a/drivers/pinctrl/actions/Makefile b/drivers/pinctrl/actions/Makefile
new file mode 100644
index ..bd232d28400f
--- /dev/null
+++ b/drivers/pinctrl/actions/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_PINCTRL_OWL) += pinctrl-owl.o
+obj-$(CONFIG_PINCTRL_S900) += pinctrl-s900.o
diff --git a/drivers/pinctrl/actions/pinctrl-owl.c
b/drivers/pinctrl/actions/pinctrl-owl.c
new file mode 100644
index ..7ed8625c30f3
--- /dev/null
+++ b/drivers/pinctrl/actions/pinctrl-owl.c
@@ -0,0 +1,573 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * OWL SoC's Pinctrl driver
+ *
+ * Copyright (c) 2014 Actions Semi Inc.
+ * Author: David Liu
+ *
+ * Copyright (c) 2018 Linaro Ltd.
+ * Author: Manivannan Sadhasivam
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../core.h"
+#include "../pinctrl-utils.h"
+#include "pinctrl-owl.h"
+
+/**
+ * struct owl_pinctrl - pinctrl state of the device
+ * @dev: device handle
+ * @pctrldev: pinctrl handle
+ * @lock: spinlock to protect registers
+ * @soc: reference to soc_data
+ * @base: pinctrl register base address
+ */
+struct owl_pinctrl {
+ struct device *dev;
+ struct pinctrl_dev *pctrldev;
+ raw_spinlock_t lock;
+ struct clk *clk;
+ const struct owl_pinctrl_soc_data *soc;
+ void __iomem *base;
+};
+
+static int owl_get_groups_count(struct pinctrl_dev *pctrldev)
+{
+ struct owl_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrldev);
+
+ return pctrl->soc->ngroups;
+}
+
+static const char *owl_get_group_name(struct pinctrl_dev *pctrldev,
+ unsigned int group)
+{
+ struct owl_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrldev);
+
+ return pctrl->soc->groups[group].name;
+}
+
+static int owl_get_group_pins(struct pinctrl_dev *pctrldev,
+ unsigned int group,
+ const unsigned int **pins,
+ unsigned int *num_pins)
+{
+ struct owl_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrldev);
+
+ *pins = pctrl->soc->groups[group].pads;
+ *num_pins = pctrl->soc->groups[group].npads;
+
+ return 0;
+}
+
+static void owl_pin_dbg_show(struct pinctrl_dev *pctrldev,
+ struct seq_file *s,
+ unsigned i
Re: [PATCH] aoe: document sysfs interface
> On Feb 17, 2018, at 9:37 AM, Julia Lawall wrote: > > > >> On Fri, 16 Feb 2018, Ed Cashin wrote: >> >>> On 02/16/2018 10:39 AM, Aishwarya Pant wrote: >>> Documentation has been compiled from git commit logs and descriptions in >>> Documentation/aoe/aoe.txt. This should be useful for scripting and >>> tracking changes in the ABI. >> ... >>> +What:/sys/block/etherd*/netif >> ... >>> +Description: >>> +(RO) The name of the network interface on the localhost >>> through >>> +which we are communicating with the remote AoE device. >> >> I'd recommend changing that to, "network interfaces". > > Should it then be "names"? Yes, s’il vous plait. Merci. — Ed
[PATCH 07/10] arm64: dts: actions: Add gpio line names to Bubblegum-96 board
Add gpio line names to Actions Semi S900 based Bubblegum-96 board.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 175 ++
1 file changed, 175 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
index ff043c961d75..2decb2c2daa4 100644
--- a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
+++ b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
@@ -34,3 +34,178 @@
status = "okay";
clocks = <&cmu CLK_UART5>;
};
+
+/*
+ * GPIO name legend: proper name = the GPIO line is used as GPIO
+ * NC = not connected (pin out but not routed from the chip to
+ * anything the board)
+ * "[PER]" = pin is muxed for [peripheral] (not GPIO)
+ * LSEC = Low Speed External Connector
+ * HSEC = High Speed External Connector
+ *
+ * Line names are taken from the schematic "Schematics Bubblegum96"
+ * version v1.0
+ *
+ * For the lines routed to the external connectors the
+ * lines are named after the 96Boards CE Specification 1.0,
+ * Appendix "Expansion Connector Signal Description".
+ *
+ * When the 96Boards naming of a line and the schematic name of
+ * the same line are in conflict, the 96Boards specification
+ * takes precedence, which means that the external UART on the
+ * LSEC is named UART0 while the schematic and SoC names this
+ * UART2. Only exception is the I2C lines for which the schematic
+ * naming has been preferred. This is only for the informational
+ * lines i.e. "[FOO]", the GPIO named lines "GPIO-A" thru "GPIO-L"
+ * are the only ones actually used for GPIO.
+ */
+
+&gpio {
+ gpio-line-names =
+ "GPIO-A", /* GPIO_0, LSEC pin 23 */
+ "GPIO-B", /* GPIO_1, LSEC pin 24 */
+ "GPIO-C", /* GPIO_2, LSEC pin 25 */
+ "GPIO-D", /* GPIO_3, LSEC pin 26 */
+ "GPIO-E", /* GPIO_4, LSEC pin 27 */
+ "GPIO-F", /* GPIO_5, LSEC pin 28 */
+ "GPIO-G", /* GPIO_6, LSEC pin 29 */
+ "GPIO-H", /* GPIO_7, LSEC pin 30 */
+ "GPIO-I", /* GPIO_8, LSEC pin 31 */
+ "GPIO-J", /* GPIO_9, LSEC pin 32 */
+ "NC", /* GPIO_10 */
+ "NC", /* GPIO_11 */
+ "SIRQ2_1V8", /* GPIO_12 */
+ "PCM0_OUT", /* GPIO_13 */
+ "WIFI_LED", /* GPIO_14 */
+ "PCM0_SYNC", /* GPIO_15 */
+ "PCM0_CLK", /* GPIO_16 */
+ "PCM0_IN", /* GPIO_17 */
+ "BT_LED", /* GPIO_18 */
+ "LED0", /* GPIO_19 */
+ "LED1", /* GPIO_20 */
+ "JTAG_TCK", /* GPIO_21 */
+ "JTAG_TMS", /* GPIO_22 */
+ "JTAG_TDI", /* GPIO_23 */
+ "JTAG_TDO", /* GPIO_24 */
+ "[UART1_RxD]", /* GPIO_25, LSEC pin 13 */
+ "NC", /* GPIO_26 */
+ "[UART1_TxD]", /* GPIO_27, LSEC pin 11 */
+ "SD0_D0", /* GPIO_28 */
+ "SD0_D1", /* GPIO_29 */
+ "SD0_D2", /* GPIO_30 */
+ "SD0_D3", /* GPIO_31 */
+ "SD1_D0", /* GPIO_32 */
+ "SD1_D1", /* GPIO_33 */
+ "SD1_D2", /* GPIO_34 */
+ "SD1_D3", /* GPIO_35 */
+ "SD0_CMD", /* GPIO_36 */
+ "SD0_CLK", /* GPIO_37 */
+ "SD1_CMD", /* GPIO_38 */
+ "SD1_CLK", /* GPIO_39 */
+ "SPI0_SCLK", /* GPIO_40, LSEC pin 8 */
+ "SPI0_CS", /* GPIO_41, LSEC pin 12 */
+ "SPI0_DIN", /* GPIO_42, LSEC pin 10 */
+ "SPI0_DOUT", /* GPIO_43, LSEC pin 14 */
+ "I2C5_SDATA", /* GPIO_44, HSEC pin 36 */
+ "I2C5_SCLK", /* GPIO_45, HSEC pin 38 */
+ "UART0_RX", /* GPIO_46, LSEC pin 7 */
+ "UART0_TX", /* GPIO_47, LSEC pin 5 */
+ "UART0_RTSB", /* GPIO_48, LSEC pin 9 */
+ "UART0_CTSB", /* GPIO_49, LSEC pin 3 */
+ "I2C4_SCLK", /* GPIO_50, HSEC pin 32 */
+ "I2C4_SDATA", /* GPIO_51, HSEC pin 34 */
+ "I2C0_SCLK", /* GPIO_52 */
+ "I2C0_SDATA", /* GPIO_53 */
+ "I2C1_SCLK", /* GPIO_54, LSEC pin 15 */
+ "I2C1_SDATA", /* GPIO_55, LSEC pin 17 */
+ "I2C2_SCLK", /* GPIO_56, LSEC pin 19 */
+ "I2C2_SDATA", /* GPIO_57, LSEC pin 21 */
+ "CSI0_DN0", /* GPIO_58, HSEC pin 10 */
+ "CSI0_DP0", /* GPIO_59, HSEC pin 8 */
+ "CSI0_DN1", /* GPIO_60, HSEC pin 16 */
+ "CSI0_DP1", /* GPIO_61, HSEC pin 14 */
+ "CSI0_CN", /* GPIO_62, HSEC pin 4 */
+ "CSI0_CP", /* GPIO_63, HSEC pin 2 */
+ "CSI0_DN2", /* GPIO_64, HSEC pin 22 */
+ "CSI0_DP2", /* GPIO_65, HSEC pin 20 */
+ "CSI0_DN3", /* GPIO_66, HSEC pin 28 */
+ "CSI0_DP3", /* GP
[PATCH 06/10] arm64: dts: actions: Add S900 gpio nodes
Add gpio nodes for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index 0156483f0f4d..e359509ad9d3 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -180,6 +180,13 @@
clocks = <&cmu CLK_GPIO>;
};
+ gpio: gpio@e01b {
+ compatible = "actions,s900-gpio";
+ reg = <0x0 0xe01b 0x0 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
timer: timer@e0228000 {
compatible = "actions,s900-timer";
reg = <0x0 0xe0228000 0x0 0x8000>;
--
2.14.1
[PATCH 03/10] arm64: actions: Enable PINCTRL in platforms Kconfig
Select PINCTRL for Actions Semi SoCs Signed-off-by: Manivannan Sadhasivam --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index fbedbd8f619a..bae1289bdc3f 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -3,6 +3,7 @@ menu "Platform selection" config ARCH_ACTIONS bool "Actions Semi Platforms" select OWL_TIMER + select PINCTRL help This enables support for the Actions Semiconductor S900 SoC family. -- 2.14.1
[PATCH 02/10] arm64: dts: actions: Add pinctrl node for S900
Add pinctrl nodes for Actions Semi S900 SoC
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index fee0c9557656..0156483f0f4d 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -174,6 +174,12 @@
#clock-cells = <1>;
};
+ pinctrl: pinctrl@e01b {
+ compatible = "actions,s900-pinctrl";
+ reg = <0x0 0xe01b 0x0 0x1000>;
+ clocks = <&cmu CLK_GPIO>;
+ };
+
timer: timer@e0228000 {
compatible = "actions,s900-timer";
reg = <0x0 0xe0228000 0x0 0x8000>;
--
2.14.1
[PATCH 00/10] Add Actions Semi S900 pinctrl and gpio support
This patchset adds pinctrl and gpio support for Actions Semi S900 SoC. Pinctrl and gpio subsystems share the common set of register range but implemented as individual drivers for making it less complex. Pinmux functions are only accessible for pin groups while pinconf parameters are available for both pin groups and individual pins. gpio-line-names has been added for the Bubblegum-96 board matching the 96Boards CE specification v1.0. Both pinctrl and gpio drivers are verified using the Bubblegum-96 board. This patchset depends on the clock driver which is still under review: https://lkml.org/lkml/2018/2/9/831 Thanks, Mani Manivannan Sadhasivam (10): dt-bindings: pinctrl: Add bindings for Actions S900 SoC arm64: dts: actions: Add pinctrl node for S900 arm64: actions: Enable PINCTRL in platforms Kconfig pinctrl: actions: Add Actions S900 pinctrl driver dt-bindings: gpio: Add gpio nodes for Actions S900 SoC arm64: dts: actions: Add S900 gpio nodes arm64: dts: actions: Add gpio line names to Bubblegum-96 board gpio: Add gpio driver for Actions OWL S900 SoC MAINTAINERS: Add reviewer for ACTIONS platforms MAINTAINERS: Add Actions Semi S900 pinctrl and gpio entries .../devicetree/bindings/gpio/actions,owl-gpio.txt | 15 + .../bindings/pinctrl/actions,s900-pinctrl.txt | 171 ++ MAINTAINERS|5 + arch/arm64/Kconfig.platforms |1 + arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 175 ++ arch/arm64/boot/dts/actions/s900.dtsi | 13 + drivers/gpio/Kconfig |8 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-owl.c| 258 ++ drivers/pinctrl/Kconfig|1 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/actions/Kconfig| 12 + drivers/pinctrl/actions/Makefile |2 + drivers/pinctrl/actions/pinctrl-owl.c | 573 + drivers/pinctrl/actions/pinctrl-owl.h | 178 ++ drivers/pinctrl/actions/pinctrl-s900.c | 2536 16 files changed, 3950 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt create mode 100644 drivers/gpio/gpio-owl.c create mode 100644 drivers/pinctrl/actions/Kconfig create mode 100644 drivers/pinctrl/actions/Makefile create mode 100644 drivers/pinctrl/actions/pinctrl-owl.c create mode 100644 drivers/pinctrl/actions/pinctrl-owl.h create mode 100644 drivers/pinctrl/actions/pinctrl-s900.c -- 2.14.1
[PATCH 01/10] dt-bindings: pinctrl: Add bindings for Actions S900 SoC
Add pinctrl bindings for Actions Semi S900 SoC Signed-off-by: Manivannan Sadhasivam --- .../bindings/pinctrl/actions,s900-pinctrl.txt | 171 + 1 file changed, 171 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt new file mode 100644 index ..ee7d3ecd9bd9 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt @@ -0,0 +1,171 @@ +Actions Semi S900 Pin Controller + +This binding describes the pin controller found in the S900 SoC. + +Required Properties: + +- compatible: Should be "actions,s900-pinctrl" +- reg: Should contain the register base address and size of +the pin controller. +- clocks: phandle of the clock feeding the pin controller + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +Pinmux functions are available only for the pin groups while pinconf +parameters are available for both pin groups and individual pins. + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +Required Properties: + +- pins: An array of strings, each string containing the name of a pin. + These pins are used for selecting the pull control and schmitt + trigger parameters. The following are the list of pins + available: + + ETH_TXD0, ETH_TXD1, ETH_TXEN, ETH_RXER, ETH_CRS_DV, + ETH_RXD1, ETH_RXD0, ETH_REF_CLK, ETH_MDC, ETH_MDIO, + SIRQ0, SIRQ1, SIRQ2, I2S_D0, I2S_BCLK0, I2S_LRCLK0, + I2S_MCLK0, I2S_D1, I2S_BCLK1, I2S_LRCLK1, I2S_MCLK1, + PCM1_IN, PCM1_CLK, PCM1_SYNC, PCM1_OUT, ERAM_A5, + ERAM_A6, ERAM_A7, ERAM_A8, ERAM_A9, ERAM_A10, ERAM_A11, + LVDS_OEP, LVDS_OEN, LVDS_ODP, LVDS_ODN, LVDS_OCP, + LVDS_OCN, LVDS_OBP, LVDS_OBN, LVDS_OAP, LVDS_OAN, + LVDS_EEP, LVDS_EEN, LVDS_EDP, LVDS_EDN, LVDS_ECP, + LVDS_ECN, LVDS_EBP, LVDS_EBN, LVDS_EAP, LVDS_EAN, + SD0_D0, SD0_D1, SD0_D2, SD0_D3, SD1_D0, SD1_D1, + SD1_D2, SD1_D3, SD0_CMD, SD0_CLK, SD1_CMD, SD1_CLK, + SPI0_SCLK, SPI0_SS, SPI0_MISO, SPI0_MOSI, UART0_RX, + UART0_TX, UART2_RX, UART2_TX, UART2_RTSB, UART2_CTSB, + UART3_RX, UART3_TX, UART3_RTSB, UART3_CTSB, UART4_RX, + UART4_TX, I2C0_SCLK, I2C0_SDATA, I2C1_SCLK, I2C1_SDATA, + I2C2_SCLK, I2C2_SDATA, CSI0_DN0, CSI0_DP0, CSI0_DN1, + CSI0_DP1, CSI0_CN, CSI0_CP, CSI0_DN2, CSI0_DP2, CSI0_DN3, + CSI0_DP3, DSI_DP3, DSI_DN3, DSI_DP1, DSI_DN1, DSI_CP, + DSI_CN, DSI_DP0, DSI_DN0, DSI_DP2, DSI_DN2, SENSOR0_PCLK, + CSI1_DN0,CSI1_DP0,CSI1_DN1, CSI1_DP1, CSI1_CN, CSI1_CP, + SENSOR0_CKOUT, NAND0_D0, NAND0_D1, NAND0_D2, NAND0_D3, + NAND0_D4, NAND0_D5, NAND0_D6, NAND0_D7, NAND0_DQS, + NAND0_DQSN, NAND0_ALE, NAND0_CLE, NAND0_CEB0, NAND0_CEB1, + NAND0_CEB2, NAND0_CEB3, NAND1_D0, NAND1_D1, NAND1_D2, + NAND1_D3, NAND1_D4, NAND1_D5, NAND1_D6, NAND1_D7, NAND1_DQS, + NAND1_DQSN, NAND1_ALE, NAND1_CLE, NAND1_CEB0, NAND1_CEB1, + NAND1_CEB2, NAND1_CEB3, SGPIO0, SGPIO1, SGPIO2, SGPIO3 + +- groups: An array of strings, each string containing the name of a pin + group. These pin groups are used for selecting the pinmux + functions. The following are the list of pin groups available: + + mfp0_22, mfp0_21_20_eth_mdc, mfp0_21_20_eth_mdio, + mfp0_19_sirq0, mfp0_19_sirq1, mfp0_18_16_eth_txd0, + mfp0_18
Re: [v3,05/11] watchdog/hpwdt: Update Module info.
On Sat, Feb 17, 2018 at 08:19:23AM -0800, Guenter Roeck wrote:
> On Thu, Feb 15, 2018 at 04:43:54PM -0700, Jerry Hoemann wrote:
> > Update Module Author and description to reflect changes in driver.
> >
> > Signed-off-by: Jerry Hoemann
> > ---
> > drivers/watchdog/hpwdt.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> > index d5989acf3e37..71e49d0ab789 100644
> > --- a/drivers/watchdog/hpwdt.c
> > +++ b/drivers/watchdog/hpwdt.c
> > @@ -425,8 +425,8 @@ static struct pci_driver hpwdt_driver = {
> > .remove = hpwdt_exit,
> > };
> >
> > -MODULE_AUTHOR("Tom Mingarelli");
> > -MODULE_DESCRIPTION("hp watchdog driver");
> > +MODULE_AUTHOR("Jerry Hoemann");
> > +MODULE_DESCRIPTION("hpe watchdog driver");
>
> It is quite unusual to replace an author name. The original author is
> still the original author and should be retained. Adding another author
> is fine, but I disagree with the removal.
Wasn't intending to usurp Tom's credit (I left him in as Author in
comment block at top of file.) But as Tom has retired, I didn't want
anyone having problems with the rewrite of the driver to bother him
about it.
I'll redact this change.
>
> Guenter
>
> > MODULE_LICENSE("GPL");
> > MODULE_VERSION(HPWDT_VERSION);
> >
--
-
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-
[PATCH] kbuild: Don't source kernel config
Don't source the kernel config file in shell scripts.
The config file is not a shell script and often imported from untrusted
sources.
What could possible go wrong? ;-)
Instead, read config file line by line and access config entries using a bash
array.
Cc: Sam Ravnborg
Cc: Arnaud Lacombe
Cc: Nick Bowler
Cc: Michal Marek
Cc: Nicolas Pitre
Cc: Rusty Russell
Fixes: 23121ca2b56b ("kbuild: create/adjust generated/autoksyms.h")
Fixes: 1f2bfbd00e46 ("kbuild: link of vmlinux moved to a script")
Signed-off-by: Richard Weinberger
---
scripts/adjust_autoksyms.sh | 13 +++--
scripts/importkconf.sh | 14 ++
scripts/link-vmlinux.sh | 23 ---
3 files changed, 25 insertions(+), 25 deletions(-)
create mode 100755 scripts/importkconf.sh
diff --git a/scripts/adjust_autoksyms.sh b/scripts/adjust_autoksyms.sh
index 513da1a4a2da..632abcd0dc69 100755
--- a/scripts/adjust_autoksyms.sh
+++ b/scripts/adjust_autoksyms.sh
@@ -39,14 +39,7 @@ case "$KBUILD_VERBOSE" in
esac
# We need access to CONFIG_ symbols
-case "${KCONFIG_CONFIG}" in
-*/*)
- . "${KCONFIG_CONFIG}"
- ;;
-*)
- # Force using a file from the current directory
- . "./${KCONFIG_CONFIG}"
-esac
+. scripts/importkconf.sh
# In case it doesn't exist yet...
if [ -e "$cur_ksyms_file" ]; then touch "$cur_ksyms_file"; fi
@@ -62,14 +55,14 @@ EOT
[ "$(ls -A "$MODVERDIR")" ] &&
sed -ns -e '3{s/ /\n/g;/^$/!p;}' "$MODVERDIR"/*.mod | sort -u |
while read sym; do
- if [ -n "$CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX" ]; then
+ if [ -n "${KERNEL_CONFIG[CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX]}" ]; then
sym="${sym#_}"
fi
echo "#define __KSYM_${sym} 1"
done >> "$new_ksyms_file"
# Special case for modversions (see modpost.c)
-if [ -n "$CONFIG_MODVERSIONS" ]; then
+if [ -n "${KERNEL_CONFIG[CONFIG_MODVERSIONS]}" ]; then
echo "#define __KSYM_module_layout 1" >> "$new_ksyms_file"
fi
diff --git a/scripts/importkconf.sh b/scripts/importkconf.sh
new file mode 100755
index ..755a9a2e9c65
--- /dev/null
+++ b/scripts/importkconf.sh
@@ -0,0 +1,14 @@
+#!/bin/bash
+#
+# helper script which reads all kconfig keys from the kernel .config file into
+# a bash associative array.
+# By testing ${KERNEL_CONFIG[CONFIG_FOO_BAR]} shell scripts can check whether
+# CONFIG_FOO_BAR is set in .config or not.
+#
+
+declare -A KERNEL_CONFIG
+
+for cfg_ent in $(awk -F= '/^CONFIG_[A-Z0-9_]+=/{print $1}' < ${KCONFIG_CONFIG})
+do
+ KERNEL_CONFIG[${cfg_ent}]="$cfg_ent"
+done
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index c0d129d7f430..c094dd8f19a2 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -55,7 +55,7 @@ info()
#
archive_builtin()
{
- if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then
+ if [ -n "${KERNEL_CONFIG[CONFIG_THIN_ARCHIVES]}" ]; then
info AR built-in.o
rm -f built-in.o;
${AR} rcsTP${KBUILD_ARFLAGS} built-in.o \
@@ -70,7 +70,7 @@ modpost_link()
{
local objects
- if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then
+ if [ -n "${KERNEL_CONFIG[CONFIG_THIN_ARCHIVES]}" ]; then
objects="--whole-archive\
built-in.o \
--no-whole-archive \
@@ -96,7 +96,7 @@ vmlinux_link()
local objects
if [ "${SRCARCH}" != "um" ]; then
- if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then
+ if [ -n "${KERNEL_CONFIG[CONFIG_THIN_ARCHIVES]}" ]; then
objects="--whole-archive\
built-in.o \
--no-whole-archive \
@@ -116,7 +116,7 @@ vmlinux_link()
${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} \
-T ${lds} ${objects}
else
- if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then
+ if [ -n "${KERNEL_CONFIG[CONFIG_THIN_ARCHIVES]}" ]; then
objects="-Wl,--whole-archive\
built-in.o \
-Wl,--no-whole-archive \
@@ -226,14 +226,7 @@ if [ "$1" = "clean" ]; then
fi
# We need access to CONFIG_ symbols
-case "${KCONFIG_CONFIG}" in
-*/*)
- . "${KCONFIG_CONFIG}"
- ;;
-*)
- # Force using a file from the current directory
- . "./${KCONFIG_CONFIG}"
-esac
+. scripts/importkconf.sh
# Update version
info GEN .version
@@ -259,7 +252,7 @@ ${MAKE} -f "${srctree}/scripts/Makefile.modpost" vmlinux.o
kallsymso=""
kallsyms_vmlinux=""
-if [ -n "${CONFIG_KALLSYMS}" ]; then
+if [ -n "${KERNEL_CONFIG[CONFIG_KALLSYMS]}" ]; then
# kallsyms support
# Generate section l
Re: [v3,04/11] watchdog/hpwdt: white space changes
On Sat, Feb 17, 2018 at 09:27:53PM +0100, Marcus Folkesson wrote:
> On Sat, Feb 17, 2018 at 12:32:08PM -0700, Jerry Hoemann wrote:
> > On Sat, Feb 17, 2018 at 08:17:34AM -0800, Guenter Roeck wrote:
> > > On Thu, Feb 15, 2018 at 04:43:53PM -0700, Jerry Hoemann wrote:
> > > > Minor white space changes and some name clean up.
> > > >
> > > > Signed-off-by: Jerry Hoemann
> > > > ---
> > > > MODULE_DEVICE_TABLE(pci, hpwdt_devices);
> > > >
> > > > @@ -102,7 +100,7 @@ static int hpwdt_time_left(void)
> > > > return TICKS_TO_SECS(ioread16(hpwdt_timer_reg));
> > > > }
> > > >
> > > > -#ifdef CONFIG_HPWDT_NMI_DECODING
> > > > +#ifdef CONFIG_HPWDT_NMI_DECODING /* { */
> > > > static int hpwdt_my_nmi(void)
> > > > {
> > > > return ioread8(hpwdt_nmistat) & 0x6;
> > > > @@ -133,7 +131,7 @@ static int hpwdt_pretimeout(unsigned int ulReason,
> > > > struct pt_regs *regs)
> > > >
> > > > return NMI_HANDLED;
> > > > }
> > > > -#endif /* CONFIG_HPWDT_NMI_DECODING */
> > > > +#endif /* } */
> > >
> > > I disagree with those changes. While I don't object to adding the '{'
> > > per se, I find it very useful to have the 'CONFIG_HPWDT_NMI_DECODING'
> > > with an endif to be able to associate it with the matching #ifdef.
>
> Well, it does not follow our coding style.
>
> Documentation/process/coding-style.rst:
>
> At the end of any non-trivial #if or #ifdef block (more than a few
> lines),
> place a comment after the #endif on the same line, noting the
> conditional
> expression used. For instance:
>
> .. code-block:: c
>
> #ifdef CONFIG_SOMETHING
> ...
> #endif /* CONFIG_SOMETHING */
>
> >
> > The matching /* { */ and /* } */ allow for quickly the finding of the
> > matching ifdef/endif.
> >
> > In the "vim" editor, the command '%' will take one from one curly paren to
> > its
> > matching curly paren...
>
> '%' in vim let you jump between matching ifdef/endif as well.
Interesting. Didn't know that. In that light, I'll redact the white space
changes.
Thanks
>
> >
> > There is a similar sequence for emacs.
> >
> > >
> > > Deferring to Wim.
> > >
> > > Guenter
> > >
> >
> > --
> >
> > -
> > Jerry Hoemann Software Engineer Hewlett Packard
> > Enterprise
> > -
>
> Thanks,
> Marcus Folkesson
--
-
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-
Re: [v3,04/11] watchdog/hpwdt: white space changes
On Sat, Feb 17, 2018 at 12:32:08PM -0700, Jerry Hoemann wrote:
> On Sat, Feb 17, 2018 at 08:17:34AM -0800, Guenter Roeck wrote:
> > On Thu, Feb 15, 2018 at 04:43:53PM -0700, Jerry Hoemann wrote:
> > > Minor white space changes and some name clean up.
> > >
> > > Signed-off-by: Jerry Hoemann
> > > ---
> > > MODULE_DEVICE_TABLE(pci, hpwdt_devices);
> > >
> > > @@ -102,7 +100,7 @@ static int hpwdt_time_left(void)
> > > return TICKS_TO_SECS(ioread16(hpwdt_timer_reg));
> > > }
> > >
> > > -#ifdef CONFIG_HPWDT_NMI_DECODING
> > > +#ifdef CONFIG_HPWDT_NMI_DECODING /* { */
> > > static int hpwdt_my_nmi(void)
> > > {
> > > return ioread8(hpwdt_nmistat) & 0x6;
> > > @@ -133,7 +131,7 @@ static int hpwdt_pretimeout(unsigned int ulReason,
> > > struct pt_regs *regs)
> > >
> > > return NMI_HANDLED;
> > > }
> > > -#endif /* CONFIG_HPWDT_NMI_DECODING */
> > > +#endif /* } */
> >
> > I disagree with those changes. While I don't object to adding the '{'
> > per se, I find it very useful to have the 'CONFIG_HPWDT_NMI_DECODING'
> > with an endif to be able to associate it with the matching #ifdef.
Well, it does not follow our coding style.
Documentation/process/coding-style.rst:
At the end of any non-trivial #if or #ifdef block (more than a few
lines),
place a comment after the #endif on the same line, noting the
conditional
expression used. For instance:
.. code-block:: c
#ifdef CONFIG_SOMETHING
...
#endif /* CONFIG_SOMETHING */
>
> The matching /* { */ and /* } */ allow for quickly the finding of the
> matching ifdef/endif.
>
> In the "vim" editor, the command '%' will take one from one curly paren to its
> matching curly paren...
'%' in vim let you jump between matching ifdef/endif as well.
>
> There is a similar sequence for emacs.
>
> >
> > Deferring to Wim.
> >
> > Guenter
> >
>
> --
>
> -
> Jerry Hoemann Software Engineer Hewlett Packard Enterprise
> -
Thanks,
Marcus Folkesson
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code
On Sat, 17 Feb 2018, Josh Poimboeuf wrote:
> On Sat, Feb 17, 2018 at 11:38:48AM +0100, Ingo Molnar wrote:
> >
> > * Josh Poimboeuf wrote:
> >
> > > +/* Disable any jump label entries in __init code */
> > > +void __init jump_label_invalidate_init(void)
> > > +{
> > > + struct jump_entry *iter_start = __start___jump_table;
> > > + struct jump_entry *iter_stop = __stop___jump_table;
> > > + struct jump_entry *iter;
> > > +
> > > + for (iter = iter_start; iter < iter_stop; iter++)
> > > + if (iter->code >= (unsigned long)_sinittext &&
> > > + iter->code < (unsigned long)_einittext)
> > > + iter->code = 0;
> > > +}
> > > +
> > > +/* Disable any jump label entries in module init code */
> > > static void jump_label_invalidate_module_init(struct module *mod)
> > > {
> > > struct jump_entry *iter_start = mod->jump_entries;
> > > struct jump_entry *iter_stop = iter_start + mod->num_jump_entries;
> > > struct jump_entry *iter;
> > >
> > > - for (iter = iter_start; iter < iter_stop; iter++) {
> > > + for (iter = iter_start; iter < iter_stop; iter++)
> > > if (within_module_init(iter->code, mod))
> > > iter->code = 0;
> > > - }
> >
> > Why did you remove the curly braces? They are canonical kernel style for
> > multi-line statements.
>
> Personally I prefer the more compact version, but I have no problem
> changing it.
Yes, it's certainly a matter of taste. Here is the reason why myself and
others prefer the version with braces:
https://marc.info/?l=linux-kernel&m=148467980905537&w=2
Thanks,
tglx
Re: [PATCH] x86/microcode: Check microcode revision before updating sibling threads
On Sat, 17 Feb 2018, Borislav Petkov wrote: > On Sat, Feb 17, 2018 at 11:42:48AM -0200, Henrique de Moraes Holschuh wrote: > > I wonder when this broke, > > It didn't break - we're just printing the update only once. It was before that change, when the microcode subsystem still printed a message for every CPU that got updated or early-updated. It was fixed to properly refresh the microcode revision in the percpu area right before deciding whether it should update that cpu or not, and thus it would skip the second thread on Intel cores because it would notice it was already up-to-date. Maybe it was just the late loader, though... I'd need to do some git log digging. -- Henrique Holschuh
Re: [v3,06/11] watchdog/hpwdt: Select WATCHDOG_CORE
On Sat, Feb 17, 2018 at 08:21:30AM -0800, Guenter Roeck wrote: > On Thu, Feb 15, 2018 at 04:43:55PM -0700, Jerry Hoemann wrote: > > Update Kconfig file to show that hpwdt now selects WATCHDOG_CORE. > > > > Signed-off-by: Jerry Hoemann > > At this point, WATCHDOG_CORE is not required. This patch should > be merged with the next patch, which adds the requirement. > > Since it appears that you insist on having it as separate patch, > deferring to Wim. > I have no objection to squashing these two commits once we have agreed upon the actual changes being made. I re-ordered to address the bisectability question, but kept them separate as it is a little bit easier for me to rework patches if the patch contains only a single file. -- - Jerry Hoemann Software Engineer Hewlett Packard Enterprise -
[PATCH v3 00/15] add dts nodes to MT7622 SoC
From: Sean Wang Changes since v2: - rebase to 4.16-rc1 and solve all conflicts - add proper list Cc in patch 1 - add fixup in patch 4 in v2 with the uniform pinmux definition that is always adding property function before property groups - add Acked-by from Philippe in patch 5 - add clock related property into all CPU nodes in patch 6 - merge patch 14 in v2 into patch 8 as this is where the node is defined in the first place Changes since v1: - add usb, thermal, HSDMA, mmc related nodes - fix Warning (unit_address_vs_reg): Node /oscillator@0 has a unit name, but no reg property in patch 2 - fix Warning (pci_bridge): Node /pcie@1a14/pcie@0,0 missing bus-range for PCI bridge - fix Warning (pci_bridge): Node /pcie@1a14/pcie@1,0 missing bus-range for PCI bridge - fix Warning (unit_address_format): Failed prerequisite 'pci_bridge' - fix Warning (pci_device_reg): Failed prerequisite 'pci_bridge' - fix Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge' - enhance commit log in patch 4 - use - instead of _ in DT node name in patch 4 and 6 - use SPDX-License-Identifier for newly added files in patch 5 - use proper #size-cells for spi nor nodes in patch 9 - remove currently no needed #address-cells and #size-cells in children nodes of spi nor in patch 9. Chunfeng Yun (1): arm64: dts: mt7622: add usb device nodes Ryder Lee (2): arm64: dts: mt7622: add PCIe device nodes arm64: dts: mt7622: add SATA device nodes Sean Wang (12): dt-bindings: clock: mediatek: add missing required #reset-cells arm64: dts: mt7622: add clock controller device nodes arm64: dts: mt7622: add power domain controller device nodes arm64: dts: mt7622: add pinctrl related device nodes arm64: dts: mt7622: add PMIC MT6380 related nodes arm64: dts: mt7622: add cpufreq related device nodes arm64: dts: mt7622: turn uart0 clock to real ones arm64: dts: mt7622: add SoC and peripheral related device nodes arm64: dts: mt7622: add flash related device nodes arm64: dts: mt7622: add ethernet device nodes arm64: dts: mt7622: add High-Speed DMA device nodes arm64: dts: mt7622: add mmc related device nodes .../bindings/arm/mediatek/mediatek,ethsys.txt | 1 + .../bindings/arm/mediatek/mediatek,pciesys.txt | 2 + .../bindings/arm/mediatek/mediatek,ssusbsys.txt| 2 + arch/arm64/boot/dts/mediatek/mt6380.dtsi | 86 +++ arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 469 ++ arch/arm64/boot/dts/mediatek/mt7622.dtsi | 685 - 6 files changed, 1240 insertions(+), 5 deletions(-) create mode 100644 arch/arm64/boot/dts/mediatek/mt6380.dtsi -- 2.7.4
[PATCH v3 13/15] arm64: dts: mt7622: add usb device nodes
From: Chunfeng Yun
add xhci node and usb3 phy nodes
Signed-off-by: Chunfeng Yun
Signed-off-by: Sean Wang
Tested-by: Jumin Li
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 28 +++
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 51
2 files changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index 6715ffa..cc89e2e 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -52,6 +52,24 @@
memory {
reg = <0 0x4000 0 0x3F00>;
};
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-5V";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
};
&pcie {
@@ -343,6 +361,16 @@
status = "okay";
};
+&ssusb {
+ vusb33-supply = <®_3p3v>;
+ vbus-supply = <®_5v>;
+ status = "okay";
+};
+
+&u3phy {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins>;
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 881bc17..bad1e99 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -535,6 +535,57 @@
#reset-cells = <1>;
};
+ ssusb: usb@1a0c {
+ compatible = "mediatek,mt7622-xhci",
+"mediatek,mtk-xhci";
+ reg = <0 0x1a0c 0 0x01000>,
+ <0 0x1a0c4700 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF1>;
+ clocks = <&ssusbsys CLK_SSUSB_SYS_EN>,
+<&ssusbsys CLK_SSUSB_REF_EN>,
+<&ssusbsys CLK_SSUSB_MCU_EN>,
+<&ssusbsys CLK_SSUSB_DMA_EN>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck";
+ phys = <&u2port0 PHY_TYPE_USB2>,
+ <&u3port0 PHY_TYPE_USB3>,
+ <&u2port1 PHY_TYPE_USB2>;
+
+ status = "disabled";
+ };
+
+ u3phy: usb-phy@1a0c4000 {
+ compatible = "mediatek,mt7622-u3phy",
+"mediatek,generic-tphy-v1";
+ reg = <0 0x1a0c4000 0 0x700>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ u2port0: usb-phy@1a0c4800 {
+ reg = <0 0x1a0c4800 0 0x0100>;
+ #phy-cells = <1>;
+ clocks = <&ssusbsys CLK_SSUSB_U2_PHY_EN>;
+ clock-names = "ref";
+ };
+
+ u3port0: usb-phy@1a0c4900 {
+ reg = <0 0x1a0c4900 0 0x0700>;
+ #phy-cells = <1>;
+ clocks = <&clk25m>;
+ clock-names = "ref";
+ };
+
+ u2port1: usb-phy@1a0c5000 {
+ reg = <0 0x1a0c5000 0 0x0100>;
+ #phy-cells = <1>;
+ clocks = <&ssusbsys CLK_SSUSB_U2_PHY_1P_EN>;
+ clock-names = "ref";
+ };
+ };
+
pciesys: pciesys@1a100800 {
compatible = "mediatek,mt7622-pciesys",
"syscon";
--
2.7.4
[PATCH v3 04/15] arm64: dts: mt7622: add pinctrl related device nodes
From: Sean Wang
add pinctrl device nodes and rfb1 board, additionally include all pin
groups possible being used on rfb1 board and available gpio keys.
Signed-off-by: Sean Wang
Cc: Matthias Brugger
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 200 +++
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 7 +
2 files changed, 207 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index c08309d..fc8ef78 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -7,6 +7,8 @@
*/
/dts-v1/;
+#include
+
#include "mt7622.dtsi"
/ {
@@ -17,11 +19,209 @@
bootargs = "console=ttyS0,115200n1";
};
+ gpio-keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ factory {
+ label = "factory";
+ linux,code = ;
+ gpios = <&pio 0 0>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = <&pio 102 0>;
+ };
+ };
+
memory {
reg = <0 0x4000 0 0x3F00>;
};
};
+&pio {
+ /* eMMC is shared pin with parallel NAND */
+ emmc_pins_default: emmc-pins-default {
+ mux {
+ function = "emmc", "emmc_rst";
+ groups = "emmc";
+ };
+ };
+
+ emmc_pins_uhs: emmc-pins-uhs {
+ mux {
+ function = "emmc";
+ groups = "emmc";
+ };
+ };
+
+ eth_pins: eth-pins {
+ mux {
+ function = "eth";
+ groups = "mdc_mdio", "rgmii_via_gmac2";
+ };
+ };
+
+ i2c1_pins: i2c1-pins {
+ mux {
+ function = "i2c";
+ groups = "i2c1_0";
+ };
+ };
+
+ i2c2_pins: i2c2-pins {
+ mux {
+ function = "i2c";
+ groups = "i2c2_0";
+ };
+ };
+
+ i2s1_pins: i2s1-pins {
+ mux {
+ function = "i2s";
+ groups = "i2s_out_bclk_ws_mclk",
+ "i2s1_in_data",
+ "i2s1_out_data";
+ };
+ };
+
+ irrx_pins: irrx-pins {
+ mux {
+ function = "ir";
+ groups = "ir_1_rx";
+ };
+ };
+
+ irtx_pins: irtx-pins {
+ mux {
+ function = "ir";
+ groups = "ir_1_tx";
+ };
+ };
+
+ /* Parallel nand is shared pin with eMMC */
+ parallel_nand_pins: parallel-nand-pins {
+ mux {
+ function = "flash";
+ groups = "par_nand";
+ };
+ };
+
+ pcie0_pins: pcie0-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie0_pad_perst",
+"pcie0_1_waken",
+"pcie0_1_clkreq";
+ };
+ };
+
+ pcie1_pins: pcie1-pins {
+ mux {
+ function = "pcie";
+ groups = "pcie1_pad_perst",
+"pcie1_0_waken",
+"pcie1_0_clkreq";
+ };
+ };
+
+ pmic_bus_pins: pmic-bus-pins {
+ mux {
+ function = "pmic";
+ groups = "pmic_bus";
+ };
+ };
+
+ pwm7_pins: pwm1-2-pins {
+ mux {
+ function = "pwm";
+ groups = "pwm_ch7_2";
+ };
+ };
+
+ wled_pins: wled-pins {
+ mux {
+ function = "led";
+ groups = "wled";
+ };
+ };
+
+ sd0_pins_default: sd0-pins-default {
+ mux {
+ function = "sd";
+ groups = "sd_0";
+ };
+ };
+
+ sd0_pins_uhs: sd0-pins-uhs {
+ mux {
+ function = "sd";
+ groups = "sd_0";
+ };
+ };
+
+ /* Serial NAND is shared pin with SPI-NOR */
+ serial_nand_pins: serial-nand-pins {
+ mux {
+ function = "flash";
+ groups = "snfi";
+ };
+ };
+
+ spic0_pins: spic0-pins {
+ mux {
+ function = "spi";
+ groups = "spic0_0";
+
[PATCH v3 11/15] arm64: dts: mt7622: add PCIe device nodes
From: Ryder Lee
This patch adds PCIe support fot MT7622.
Signed-off-by: Ryder Lee
Signed-off-by: Sean Wang
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 10
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 74
2 files changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index e2bd93e..72ef443 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -54,6 +54,16 @@
};
};
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_pins>;
+ status = "okay";
+
+ pcie@0,0 {
+ status = "okay";
+ };
+};
+
&pio {
/* eMMC is shared pin with parallel NAND */
emmc_pins_default: emmc-pins-default {
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 95f947e..cc026eb 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -542,6 +542,80 @@
#reset-cells = <1>;
};
+ pcie: pcie@1a14 {
+ compatible = "mediatek,mt7622-pcie";
+ device_type = "pci";
+ reg = <0 0x1a14 0 0x1000>,
+ <0 0x1a143000 0 0x1000>,
+ <0 0x1a145000 0 0x1000>;
+ reg-names = "subsys", "port0", "port1";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ interrupts = ,
+;
+ clocks = <&pciesys CLK_PCIE_P0_MAC_EN>,
+<&pciesys CLK_PCIE_P1_MAC_EN>,
+<&pciesys CLK_PCIE_P0_AHB_EN>,
+<&pciesys CLK_PCIE_P0_AHB_EN>,
+<&pciesys CLK_PCIE_P0_AUX_EN>,
+<&pciesys CLK_PCIE_P1_AUX_EN>,
+<&pciesys CLK_PCIE_P0_AXI_EN>,
+<&pciesys CLK_PCIE_P1_AXI_EN>,
+<&pciesys CLK_PCIE_P0_OBFF_EN>,
+<&pciesys CLK_PCIE_P1_OBFF_EN>,
+<&pciesys CLK_PCIE_P0_PIPE_EN>,
+<&pciesys CLK_PCIE_P1_PIPE_EN>;
+ clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1",
+ "aux_ck0", "aux_ck1", "axi_ck0", "axi_ck1",
+ "obff_ck0", "obff_ck1", "pipe_ck0", "pipe_ck1";
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+ bus-range = <0x00 0xff>;
+ ranges = <0x8200 0 0x2000 0x0 0x2000 0 0x1000>;
+ status = "disabled";
+
+ pcie0: pcie@0,0 {
+ reg = <0x 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ num-lanes = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc0 0>,
+ <0 0 0 2 &pcie_intc0 1>,
+ <0 0 0 3 &pcie_intc0 2>,
+ <0 0 0 4 &pcie_intc0 3>;
+ pcie_intc0: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ pcie1: pcie@1,0 {
+ reg = <0x0800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ num-lanes = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+ <0 0 0 2 &pcie_intc1 1>,
+ <0 0 0 3 &pcie_intc1 2>,
+ <0 0 0 4 &pcie_intc1 3>;
+ pcie_intc1: interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt7622-ethsys",
"syscon";
--
2.7.4
[PATCH v3 01/15] dt-bindings: clock: mediatek: add missing required #reset-cells
From: Sean Wang
All ethsys, pciesys and ssusbsys internally include reset controller, so
explicitly add back these missing cell definitions to related bindings
and examples.
Signed-off-by: Sean Wang
Cc: Rob Herring
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt | 2 ++
Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt | 2 ++
3 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
index 6cc7840..8f5335b 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
@@ -9,6 +9,7 @@ Required Properties:
- "mediatek,mt2701-ethsys", "syscon"
- "mediatek,mt7622-ethsys", "syscon"
- #clock-cells: Must be 1
+- #reset-cells: Must be 1
The ethsys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
index d5d5f12..7fe5dc6 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be:
- "mediatek,mt7622-pciesys", "syscon"
- #clock-cells: Must be 1
+- #reset-cells: Must be 1
The PCIESYS controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -19,4 +20,5 @@ pciesys: pciesys@1a100800 {
compatible = "mediatek,mt7622-pciesys", "syscon";
reg = <0 0x1a100800 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
index 00760019..b8184da 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be:
- "mediatek,mt7622-ssusbsys", "syscon"
- #clock-cells: Must be 1
+- #reset-cells: Must be 1
The SSUSBSYS controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -19,4 +20,5 @@ ssusbsys: ssusbsys@1a00 {
compatible = "mediatek,mt7622-ssusbsys", "syscon";
reg = <0 0x1a00 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
--
2.7.4
[PATCH v3 07/15] arm64: dts: mt7622: turn uart0 clock to real ones
From: Sean Wang
This patch also cleans up two oscillators that provide clocks for MT7623.
Switch the uart clocks to the real ones while at it.
Signed-off-by: Sean Wang
Cc: Matthias Brugger
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 7256879..d8a17d1 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -91,18 +91,6 @@
};
};
- uart_clk: dummy25m {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <2500>;
- };
-
- bus_clk: dummy280m {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <28000>;
- };
-
pwrap_clk: dummy40m {
compatible = "fixed-clock";
clock-frequency = <4000>;
@@ -234,7 +222,8 @@
"mediatek,mt6577-uart";
reg = <0 0x11002000 0 0x400>;
interrupts = ;
- clocks = <&uart_clk>, <&bus_clk>;
+ clocks = <&topckgen CLK_TOP_UART_SEL>,
+<&pericfg CLK_PERI_UART1_PD>;
clock-names = "baud", "bus";
status = "disabled";
};
--
2.7.4
[PATCH v3 02/15] arm64: dts: mt7622: add clock controller device nodes
From: Sean Wang
Add clock controller nodes for MT7622 and include header for topckgen,
infracfg, pericfg, apmixedsys, ethsys, sgmiisys, pciesys and ssusbsys
for those devices nodes to be added afterwards.
In addition, provides an oscillator node for the source of PLLs and dummy
clock for PWARP to complement missing support of clock gate for the
wrapper circuit in the driver.
Signed-off-by: Sean Wang
Cc: Stephen Boyd
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 76
1 file changed, 76 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index b111fec..73e5d62 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -8,6 +8,8 @@
#include
#include
+#include
+#include
/ {
compatible = "mediatek,mt7622";
@@ -48,6 +50,19 @@
clock-frequency = <28000>;
};
+ pwrap_clk: dummy40m {
+ compatible = "fixed-clock";
+ clock-frequency = <4000>;
+ #clock-cells = <0>;
+ };
+
+ clk25m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ clock-output-names = "clkxtal";
+ };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
@@ -78,6 +93,22 @@
IRQ_TYPE_LEVEL_HIGH)>;
};
+ infracfg: infracfg@1000 {
+ compatible = "mediatek,mt7622-infracfg",
+"syscon";
+ reg = <0 0x1000 0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ pericfg: pericfg@10002000 {
+ compatible = "mediatek,mt7622-pericfg",
+"syscon";
+ reg = <0 0x10002000 0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
sysirq: interrupt-controller@10200620 {
compatible = "mediatek,mt7622-sysirq",
"mediatek,mt6577-sysirq";
@@ -87,6 +118,20 @@
reg = <0 0x10200620 0 0x20>;
};
+ apmixedsys: apmixedsys@10209000 {
+ compatible = "mediatek,mt7622-apmixedsys",
+"syscon";
+ reg = <0 0x10209000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ topckgen: topckgen@1021 {
+ compatible = "mediatek,mt7622-topckgen",
+"syscon";
+ reg = <0 0x1021 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
gic: interrupt-controller@1030 {
compatible = "arm,gic-400";
interrupt-controller;
@@ -107,4 +152,35 @@
clock-names = "baud", "bus";
status = "disabled";
};
+
+ ssusbsys: ssusbsys@1a00 {
+ compatible = "mediatek,mt7622-ssusbsys",
+"syscon";
+ reg = <0 0x1a00 0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ pciesys: pciesys@1a100800 {
+ compatible = "mediatek,mt7622-pciesys",
+"syscon";
+ reg = <0 0x1a100800 0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ ethsys: syscon@1b00 {
+ compatible = "mediatek,mt7622-ethsys",
+"syscon";
+ reg = <0 0x1b00 0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ sgmiisys: sgmiisys@1b128000 {
+ compatible = "mediatek,mt7622-sgmiisys",
+"syscon";
+ reg = <0 0x1b128000 0 0x1000>;
+ #clock-cells = <1>;
+ };
};
--
2.7.4
[PATCH v3 05/15] arm64: dts: mt7622: add PMIC MT6380 related nodes
From: Sean Wang
Enable pwrap and MT6380 on mt7622-rfb1 board. Also add all mt6380
regulator nodes in an alone file to allow similar boards using MT6380
able to resue the configuration.
Signed-off-by: Sean Wang
Cc: Mark Brown
Cc: Matthias Brugger
Cc: Philippe Ombredanne
Acked-by: Philippe Ombredanne
---
arch/arm64/boot/dts/mediatek/mt6380.dtsi | 86
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 8 +++
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 12
3 files changed, 106 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6380.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/mt6380.dtsi
b/arch/arm64/boot/dts/mediatek/mt6380.dtsi
new file mode 100644
index 000..53b335d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6380.dtsi
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for MediaTek MT6380 regulator
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Chenglin Xu
+ *Sean Wang
+ */
+
+&pwrap {
+ regulators {
+ compatible = "mediatek,mt6380-regulator";
+
+ mt6380_vcpu_reg: buck-vcore1 {
+ regulator-name = "vcore1";
+ regulator-min-microvolt = < 60>;
+ regulator-max-microvolt = <1393750>;
+ regulator-ramp-delay = <6250>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6380_vcore_reg: buck-vcore {
+ regulator-name = "vcore";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <1393750>;
+ regulator-ramp-delay = <6250>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6380_vrf_reg: buck-vrf {
+ regulator-name = "vrf";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <1575000>;
+ regulator-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6380_vm_reg: ldo-vm {
+ regulator-name = "vm";
+ regulator-min-microvolt = <105>;
+ regulator-max-microvolt = <140>;
+ regulator-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6380_va_reg: ldo-va {
+ regulator-name = "va";
+ regulator-min-microvolt = <220>;
+ regulator-max-microvolt = <330>;
+ regulator-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6380_vphy_reg: ldo-vphy {
+ regulator-name = "vphy";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6380_vddr_reg: ldo-vddr {
+ regulator-name = "vddr";
+ regulator-min-microvolt = <124>;
+ regulator-max-microvolt = <184>;
+ regulator-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ mt6380_vt_reg: ldo-vt {
+ regulator-name = "vt";
+ regulator-min-microvolt = <220>;
+ regulator-max-microvolt = <330>;
+ regulator-ramp-delay = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index fc8ef78..42bd3a4 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -10,6 +10,7 @@
#include
#include "mt7622.dtsi"
+#include "mt6380.dtsi"
/ {
model = "MediaTek MT7622 RFB1 board";
@@ -222,6 +223,13 @@
};
};
+&pwrap {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_bus_pins>;
+
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 8211bf7..c387c4c 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -102,6 +102,18 @@
#reset-cells = <1>;
};
+ pwrap: pwrap@10001000 {
+
[PATCH v3 15/15] arm64: dts: mt7622: add mmc related device nodes
From: Sean Wang
add mmc device nodes and proper setup for used pins
Signed-off-by: Sean Wang
Signed-off-by: Jimin Wang
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 106 +++
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 20 +
2 files changed, 126 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index cc89e2e..45d8655 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include
+#include
#include "mt7622.dtsi"
#include "mt6380.dtsi"
@@ -53,6 +54,14 @@
reg = <0 0x4000 0 0x3F00>;
};
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
reg_3p3v: regulator-3p3v {
compatible = "regulator-fixed";
regulator-name = "fixed-3.3V";
@@ -89,6 +98,23 @@
function = "emmc", "emmc_rst";
groups = "emmc";
};
+
+ /* "NDL0","NDL1","NDL2","NDL3","NDL4","NDL5","NDL6","NDL7",
+* "NRB","NCLE" pins are used as DAT0,DAT1,DAT2,DAT3,DAT4,
+* DAT5,DAT6,DAT7,CMD,CLK for eMMC respectively
+*/
+ conf-cmd-dat {
+ pins = "NDL0", "NDL1", "NDL2",
+ "NDL3", "NDL4", "NDL5",
+ "NDL6", "NDL7", "NRB";
+ input-enable;
+ bias-pull-up;
+ };
+
+ conf-clk {
+ pins = "NCLE";
+ bias-pull-down;
+ };
};
emmc_pins_uhs: emmc-pins-uhs {
@@ -96,6 +122,21 @@
function = "emmc";
groups = "emmc";
};
+
+ conf-cmd-dat {
+ pins = "NDL0", "NDL1", "NDL2",
+ "NDL3", "NDL4", "NDL5",
+ "NDL6", "NDL7", "NRB";
+ input-enable;
+ drive-strength = <4>;
+ bias-pull-up;
+ };
+
+ conf-clk {
+ pins = "NCLE";
+ drive-strength = <4>;
+ bias-pull-down;
+ };
};
eth_pins: eth-pins {
@@ -194,6 +235,27 @@
function = "sd";
groups = "sd_0";
};
+
+ /* "I2S2_OUT, "I2S4_IN"", "I2S3_IN", "I2S2_IN",
+* "I2S4_OUT", "I2S3_OUT" are used as DAT0, DAT1,
+* DAT2, DAT3, CMD, CLK for SD respectively.
+*/
+ conf-cmd-data {
+ pins = "I2S2_OUT", "I2S4_IN", "I2S3_IN",
+ "I2S2_IN","I2S4_OUT";
+ input-enable;
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+ conf-clk {
+ pins = "I2S3_OUT";
+ drive-strength = <12>;
+ bias-pull-down;
+ };
+ conf-cd {
+ pins = "TXD3";
+ bias-pull-up;
+ };
};
sd0_pins_uhs: sd0-pins-uhs {
@@ -201,6 +263,18 @@
function = "sd";
groups = "sd_0";
};
+
+ conf-cmd-data {
+ pins = "I2S2_OUT", "I2S4_IN", "I2S3_IN",
+ "I2S2_IN","I2S4_OUT";
+ input-enable;
+ bias-pull-up;
+ };
+
+ conf-clk {
+ pins = "I2S3_OUT";
+ bias-pull-down;
+ };
};
/* Serial NAND is shared pin with SPI-NOR */
@@ -311,6 +385,38 @@
status = "okay";
};
+&mmc0 {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <&emmc_pins_default>;
+ pinctrl-1 = <&emmc_pins_uhs>;
+ status = "okay";
+ bus-width = <8>;
+ max-frequency = <5000>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ assigned-clocks = <&topckgen CLK_TOP_MSDC30_0_SEL>;
+ assigned-clock-parents = <&topckgen CLK_TOP_UNIV48M>;
+ non-removable;
+};
+
+&mmc1 {
+ pinctrl-names = "default", "state_uhs";
+ pinctrl-0 = <&sd0_pins_default>;
+ pinctrl-1 = <&sd0_pins_uhs>;
+ status = "okay";
+ bus-width = <4>;
+ max-frequency = <5000>;
+ cap-sd-highspeed;
+ r_s
[PATCH v3 14/15] arm64: dts: mt7622: add High-Speed DMA device nodes
From: Sean Wang
add High-Speed DMA (HSDMA) nodes
Signed-off-by: Sean Wang
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index bad1e99..ffb934b 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -715,6 +715,16 @@
#reset-cells = <1>;
};
+ hsdma: dma-controller@1b007000 {
+ compatible = "mediatek,mt7622-hsdma";
+ reg = <0 0x1b007000 0 0x1000>;
+ interrupts = ;
+ clocks = <ðsys CLK_ETH_HSDMA_EN>;
+ clock-names = "hsdma";
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_ETHSYS>;
+ #dma-cells = <1>;
+ };
+
eth: ethernet@1b10 {
compatible = "mediatek,mt7622-eth",
"mediatek,mt2701-eth",
--
2.7.4
[PATCH v3 03/15] arm64: dts: mt7622: add power domain controller device nodes
From: Sean Wang
add power domain controller nodes
Signed-off-by: Sean Wang
Cc: Matthias Brugger
---
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 73e5d62..81207e6 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -109,6 +110,20 @@
#reset-cells = <1>;
};
+ scpsys: scpsys@10006000 {
+ compatible = "mediatek,mt7622-scpsys",
+"syscon";
+ #power-domain-cells = <1>;
+ reg = <0 0x10006000 0 0x1000>;
+ interrupts = ,
+,
+,
+;
+ infracfg = <&infracfg>;
+ clocks = <&topckgen CLK_TOP_HIF_SEL>;
+ clock-names = "hif_sel";
+ };
+
sysirq: interrupt-controller@10200620 {
compatible = "mediatek,mt7622-sysirq",
"mediatek,mt6577-sysirq";
--
2.7.4
[PATCH v3 12/15] arm64: dts: mt7622: add SATA device nodes
From: Ryder Lee
This patch adds SATA support fot MT7622.
Signed-off-by: Ryder Lee
Signed-off-by: Sean Wang
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 8 ++
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 40
2 files changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index 72ef443..6715ffa 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -323,6 +323,14 @@
status = "okay";
};
+&sata {
+ status = "okay";
+};
+
+&sata_phy {
+ status = "okay";
+};
+
&spi0 {
pinctrl-names = "default";
pinctrl-0 = <&spic0_pins>;
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index cc026eb..881bc17 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -616,6 +617,45 @@
};
};
+ sata: sata@1a20 {
+ compatible = "mediatek,mt7622-ahci",
+"mediatek,mtk-ahci";
+ reg = <0 0x1a20 0 0x1100>;
+ interrupts = ;
+ interrupt-names = "hostc";
+ clocks = <&pciesys CLK_SATA_AHB_EN>,
+<&pciesys CLK_SATA_AXI_EN>,
+<&pciesys CLK_SATA_ASIC_EN>,
+<&pciesys CLK_SATA_RBC_EN>,
+<&pciesys CLK_SATA_PM_EN>;
+ clock-names = "ahb", "axi", "asic", "rbc", "pm";
+ phys = <&sata_port PHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ ports-implemented = <0x1>;
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+ resets = <&pciesys MT7622_SATA_AXI_BUS_RST>,
+<&pciesys MT7622_SATA_PHY_SW_RST>,
+<&pciesys MT7622_SATA_PHY_REG_RST>;
+ reset-names = "axi", "sw", "reg";
+ mediatek,phy-mode = <&pciesys>;
+ status = "disabled";
+ };
+
+ sata_phy: sata-phy@1a243000 {
+ compatible = "mediatek,generic-tphy-v1";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ sata_port: sata-phy@1a243000 {
+ reg = <0 0x1a243000 0 0x0100>;
+ clocks = <&topckgen CLK_TOP_ETH_500M>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ };
+ };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt7622-ethsys",
"syscon";
--
2.7.4
[PATCH v3 08/15] arm64: dts: mt7622: add SoC and peripheral related device nodes
From: Sean Wang
Add watchdog, rtc, auxadc, cir, efuse, rng, uart[1-4], pwm, i2c[0-2],
spi[0-1], btif and thermal related nodes.
Signed-off-by: Sean Wang
Cc: Andrew-CT Chen
Cc: Zhiyong Tao
Cc: Zhi Mao
Cc: Jun Gao
Cc: Leilk Liu
Cc: Matthias Brugger
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 54 ++
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 264 +++
2 files changed, 318 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index b387865..ba6a79c 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -235,6 +235,34 @@
};
};
+&btif {
+ status = "okay";
+};
+
+&cir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&irrx_pins>;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+ status = "okay";
+};
+
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm7_pins>;
+ status = "okay";
+};
+
&pwrap {
pinctrl-names = "default";
pinctrl-0 = <&pmic_bus_pins>;
@@ -242,6 +270,32 @@
status = "okay";
};
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spic0_pins>;
+ status = "okay";
+};
+
+&spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spic1_pins>;
+ status = "okay";
+};
+
&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "okay";
+};
+
+&watchdog {
+ pinctrl-names = "default";
+ pinctrl-0 = <&watchdog_pins>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index d8a17d1..448cd36 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt7622";
@@ -74,6 +75,7 @@
<&apmixedsys CLK_APMIXED_MAIN_CORE_EN>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>;
enable-method = "psci";
clock-frequency = <13>;
};
@@ -121,6 +123,58 @@
};
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <&thermal 0>;
+
+ trips {
+ cpu_passive: cpu-passive {
+ temperature = <47000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_active: cpu-active {
+ temperature = <67000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu-hot {
+ temperature = <87000>;
+ hysteresis = <2000>;
+ type = "hot";
+ };
+
+ cpu-crit {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_passive>;
+ cooling-device = <&cpu0
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+
+ map1 {
+ trip = <&cpu_active>;
+ cooling-device = <&cpu0
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+
+ map2 {
+ trip = <&cpu_hot>;
+ cooling-device = <&cpu0
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
@@ -176,6 +230,16 @@
clock-names = "hif_sel"
[PATCH v3 10/15] arm64: dts: mt7622: add ethernet device nodes
From: Sean Wang
add ethernet device nodes which enable GMAC1 with SGMII interface
Signed-off-by: Sean Wang
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 22
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 31
2 files changed, 53 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index 48c5ba4..e2bd93e 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -249,6 +249,28 @@
status = "okay";
};
+ð {
+ pinctrl-names = "default";
+ pinctrl-0 = <ð_pins>;
+ status = "okay";
+
+ gmac1: mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+ phy-handle = <&phy5>;
+ };
+
+ mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ phy-mode = "sgmii";
+ };
+ };
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index d287d75..95f947e 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -550,6 +550,37 @@
#reset-cells = <1>;
};
+ eth: ethernet@1b10 {
+ compatible = "mediatek,mt7622-eth",
+"mediatek,mt2701-eth",
+"syscon";
+ reg = <0 0x1b10 0 0x2>;
+ interrupts = ,
+,
+;
+ clocks = <&topckgen CLK_TOP_ETH_SEL>,
+<ðsys CLK_ETH_ESW_EN>,
+<ðsys CLK_ETH_GP0_EN>,
+<ðsys CLK_ETH_GP1_EN>,
+<ðsys CLK_ETH_GP2_EN>,
+<&sgmiisys CLK_SGMII_TX250M_EN>,
+<&sgmiisys CLK_SGMII_RX250M_EN>,
+<&sgmiisys CLK_SGMII_CDR_REF>,
+<&sgmiisys CLK_SGMII_CDR_FB>,
+<&topckgen CLK_TOP_SGMIIPLL>,
+<&apmixedsys CLK_APMIXED_ETH2PLL>;
+ clock-names = "ethif", "esw", "gp0", "gp1", "gp2",
+ "sgmii_tx250m", "sgmii_rx250m",
+ "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii_ck",
+ "eth2pll";
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_ETHSYS>;
+ mediatek,ethsys = <ðsys>;
+ mediatek,sgmiisys = <&sgmiisys>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
sgmiisys: sgmiisys@1b128000 {
compatible = "mediatek,mt7622-sgmiisys",
"syscon";
--
2.7.4
[PATCH v3 06/15] arm64: dts: mt7622: add cpufreq related device nodes
From: Sean Wang
Add clocks, regulators and opp information into cpu nodes.
In addition, the power supply for cpu nodes is deployed on
mt7622-rfb1 board.
Signed-off-by: Sean Wang
Cc: Viresh Kumar
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 12 +++
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 52
2 files changed, 64 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index 42bd3a4..b387865 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -20,6 +20,18 @@
bootargs = "console=ttyS0,115200n1";
};
+ cpus {
+ cpu@0 {
+ proc-supply = <&mt6380_vcpu_reg>;
+ sram-supply = <&mt6380_vm_reg>;
+ };
+
+ cpu@1 {
+ proc-supply = <&mt6380_vcpu_reg>;
+ sram-supply = <&mt6380_vm_reg>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys-polled";
poll-interval = <100>;
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index c387c4c..7256879 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -18,6 +18,50 @@
#address-cells = <2>;
#size-cells = <2>;
+ cpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+ opp-shared;
+ opp-3 {
+ opp-hz = /bits/ 64 <3000>;
+ opp-microvolt = <95>;
+ };
+
+ opp-43750 {
+ opp-hz = /bits/ 64 <43750>;
+ opp-microvolt = <100>;
+ };
+
+ opp-6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <105>;
+ };
+
+ opp-81250 {
+ opp-hz = /bits/ 64 <81250>;
+ opp-microvolt = <110>;
+ };
+
+ opp-102500 {
+ opp-hz = /bits/ 64 <102500>;
+ opp-microvolt = <115>;
+ };
+
+ opp-113750 {
+ opp-hz = /bits/ 64 <113750>;
+ opp-microvolt = <120>;
+ };
+
+ opp-126250 {
+ opp-hz = /bits/ 64 <126250>;
+ opp-microvolt = <125>;
+ };
+
+ opp-135000 {
+ opp-hz = /bits/ 64 <135000>;
+ opp-microvolt = <131>;
+ };
+ };
+
cpus {
#address-cells = <2>;
#size-cells = <0>;
@@ -26,6 +70,10 @@
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x0>;
+ clocks = <&infracfg CLK_INFRA_MUX1_SEL>,
+<&apmixedsys CLK_APMIXED_MAIN_CORE_EN>;
+ clock-names = "cpu", "intermediate";
+ operating-points-v2 = <&cpu_opp_table>;
enable-method = "psci";
clock-frequency = <13>;
};
@@ -34,6 +82,10 @@
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x0 0x1>;
+ clocks = <&infracfg CLK_INFRA_MUX1_SEL>,
+<&apmixedsys CLK_APMIXED_MAIN_CORE_EN>;
+ clock-names = "cpu", "intermediate";
+ operating-points-v2 = <&cpu_opp_table>;
enable-method = "psci";
clock-frequency = <13>;
};
--
2.7.4
[PATCH v3 09/15] arm64: dts: mt7622: add flash related device nodes
From: Sean Wang
add nodes for NOR flash, parallel Nand flash with error correction code
support.
Signed-off-by: Sean Wang
Cc: RogerCC Lin
Cc: Guochun Mao
---
arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 21 +
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 34
2 files changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index ba6a79c..48c5ba4 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -235,6 +235,10 @@
};
};
+&bch {
+ status = "disabled";
+};
+
&btif {
status = "okay";
};
@@ -257,6 +261,23 @@
status = "okay";
};
+&nandc {
+ pinctrl-names = "default";
+ pinctrl-0 = <¶llel_nand_pins>;
+ status = "disabled";
+};
+
+&nor_flash {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi_nor_pins>;
+ status = "disabled";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+};
+
&pwm {
pinctrl-names = "default";
pinctrl-0 = <&pwm7_pins>;
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 448cd36..d287d75 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -468,6 +468,40 @@
status = "disabled";
};
+ nandc: nfi@1100d000 {
+ compatible = "mediatek,mt7622-nfc";
+ reg = <0 0x1100D000 0 0x1000>;
+ interrupts = ;
+ clocks = <&pericfg CLK_PERI_NFI_PD>,
+<&pericfg CLK_PERI_SNFI_PD>;
+ clock-names = "nfi_clk", "pad_clk";
+ ecc-engine = <&bch>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ bch: ecc@1100e000 {
+ compatible = "mediatek,mt7622-ecc";
+ reg = <0 0x1100e000 0 0x1000>;
+ interrupts = ;
+ clocks = <&pericfg CLK_PERI_NFIECC_PD>;
+ clock-names = "nfiecc_clk";
+ status = "disabled";
+ };
+
+ nor_flash: spi@11014000 {
+ compatible = "mediatek,mt7622-nor",
+"mediatek,mt8173-nor";
+ reg = <0 0x11014000 0 0xe0>;
+ clocks = <&pericfg CLK_PERI_FLASH_PD>,
+<&topckgen CLK_TOP_FLASH_SEL>;
+ clock-names = "spi", "sf";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi1: spi@11016000 {
compatible = "mediatek,mt7622-spi";
reg = <0 0x11016000 0 0x100>;
--
2.7.4
Re: syscon regmap for disabled node?
On Sat, Feb 17, 2018 at 2:40 AM, Suman Anna wrote:
> Hi Pankaj, Arnd, Lee,
>
> I am testing some code to use a syscon/regmap interface and I find that
> the syscon/regmap is initialized even on a disabled device node using a
> "syscon" compatible property when I have expected it to fail. Prior to
> commit bdb0066df96e ("mfd: syscon: Decouple syscon interface from
> platform devices"), the driver would have never probed, and the
> of_syscon_register() only checks for the compatible, but not if the
> device node is available. Is this intentional or a bug?
My guess would be that nothing relies on the current behavior and that
it could be changed if it causes problems, but it's hard to tell for the general
case.
Can you describe why you have a disabled syscon node? Most uses of the
status property are for on-chip devices that we disable because nothing is
connected to them, but that seems unlikely for a syscon.
Arnd
[PATCH] auxdisplay: Replace licenses with SPDX identifiers
Cc: Willy Tarreau Cc: Geert Uytterhoeven Cc: Linus Walleij Cc: Robin van der Gracht Cc: Paul Burton Signed-off-by: Miguel Ojeda --- Please let me know if you agree for your files and I will queue it up. Thanks! drivers/auxdisplay/arm-charlcd.c| 2 +- drivers/auxdisplay/cfag12864b.c | 16 +--- drivers/auxdisplay/cfag12864bfb.c | 16 +--- drivers/auxdisplay/charlcd.c| 6 +- drivers/auxdisplay/hd44780.c| 6 +- drivers/auxdisplay/ht16k33.c| 10 +- drivers/auxdisplay/img-ascii-lcd.c | 6 +- drivers/auxdisplay/ks0108.c | 16 +--- drivers/auxdisplay/panel.c | 6 +- include/linux/cfag12864b.h | 16 +--- include/linux/ks0108.h | 16 +--- samples/auxdisplay/cfag12864b-example.c | 16 +--- 12 files changed, 12 insertions(+), 120 deletions(-) diff --git a/drivers/auxdisplay/arm-charlcd.c b/drivers/auxdisplay/arm-charlcd.c index b3176ee92b90..ec5bd065d0d5 100644 --- a/drivers/auxdisplay/arm-charlcd.c +++ b/drivers/auxdisplay/arm-charlcd.c @@ -1,10 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Driver for the on-board character LCD found on some ARM reference boards * This is basically an Hitachi HD44780 LCD with a custom IP block to drive it * http://en.wikipedia.org/wiki/HD44780_Character_LCD * Currently it will just display the text "ARM Linux" and the linux version * - * License terms: GNU General Public License (GPL) version 2 * Author: Linus Walleij */ #include diff --git a/drivers/auxdisplay/cfag12864b.c b/drivers/auxdisplay/cfag12864b.c index 41ce4bd96813..6bd2f65e116a 100644 --- a/drivers/auxdisplay/cfag12864b.c +++ b/drivers/auxdisplay/cfag12864b.c @@ -1,26 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0 /* *Filename: cfag12864b.c * Version: 0.1.0 * Description: cfag12864b LCD driver - * License: GPLv2 * Depends: ks0108 * * Author: Copyright (C) Miguel Ojeda Sandonis *Date: 2006-10-31 - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License 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. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * */ #include diff --git a/drivers/auxdisplay/cfag12864bfb.c b/drivers/auxdisplay/cfag12864bfb.c index a3874034e2ce..898d14ca8ac8 100644 --- a/drivers/auxdisplay/cfag12864bfb.c +++ b/drivers/auxdisplay/cfag12864bfb.c @@ -1,26 +1,12 @@ +// SPDX-License-Identifier: GPL-2.0 /* *Filename: cfag12864bfb.c * Version: 0.1.0 * Description: cfag12864b LCD framebuffer driver - * License: GPLv2 * Depends: cfag12864b * * Author: Copyright (C) Miguel Ojeda Sandonis *Date: 2006-10-31 - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License 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. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * */ #include diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c index 642afd88870b..dc187a7a1a67 100644 --- a/drivers/auxdisplay/charlcd.c +++ b/drivers/auxdisplay/charlcd.c @@ -1,13 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * Character LCD driver for Linux * * Copyright (C) 2000-2008, Willy Tarreau * Copyright (C) 2016-2017 Glider bvba - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version - * 2 of the License, or (at your option) any later version. */ #include diff --git a/drivers/auxdisplay/hd44780.c b/drivers/auxdisplay/hd44780.c index 036eec404289..78d8f1986fec 100644 --- a/drivers/auxdisplay/hd44780.c +++ b/drivers/auxdisplay/hd44780.c @@ -1,13 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * HD44780 Character LCD driver for Linux * * Copyright (C) 2000-2008, Willy Tarreau * Copyright (C) 2016
Re: [v3,04/11] watchdog/hpwdt: white space changes
On Sat, Feb 17, 2018 at 08:17:34AM -0800, Guenter Roeck wrote:
> On Thu, Feb 15, 2018 at 04:43:53PM -0700, Jerry Hoemann wrote:
> > Minor white space changes and some name clean up.
> >
> > Signed-off-by: Jerry Hoemann
> > ---
> > MODULE_DEVICE_TABLE(pci, hpwdt_devices);
> >
> > @@ -102,7 +100,7 @@ static int hpwdt_time_left(void)
> > return TICKS_TO_SECS(ioread16(hpwdt_timer_reg));
> > }
> >
> > -#ifdef CONFIG_HPWDT_NMI_DECODING
> > +#ifdef CONFIG_HPWDT_NMI_DECODING /* { */
> > static int hpwdt_my_nmi(void)
> > {
> > return ioread8(hpwdt_nmistat) & 0x6;
> > @@ -133,7 +131,7 @@ static int hpwdt_pretimeout(unsigned int ulReason,
> > struct pt_regs *regs)
> >
> > return NMI_HANDLED;
> > }
> > -#endif /* CONFIG_HPWDT_NMI_DECODING */
> > +#endif /* } */
>
> I disagree with those changes. While I don't object to adding the '{'
> per se, I find it very useful to have the 'CONFIG_HPWDT_NMI_DECODING'
> with an endif to be able to associate it with the matching #ifdef.
The matching /* { */ and /* } */ allow for quickly the finding of the
matching ifdef/endif.
In the "vim" editor, the command '%' will take one from one curly paren to its
matching curly paren...
There is a similar sequence for emacs.
>
> Deferring to Wim.
>
> Guenter
>
--
-
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-
Re: [PATCH V2] lib/scatterlist: Add SG_CHAIN and SG_END macros for LSB encodings
Hi Anshuman, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc1 next-20180216] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/lib-scatterlist-Add-SG_CHAIN-and-SG_END-macros-for-LSB-encodings/20180218-015554 config: x86_64-randconfig-s3-02180201 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): In file included from drivers/staging/rts5208/rtsx.h:180:0, from drivers/staging/rts5208/rtsx.c:28: >> drivers/staging/rts5208/rtsx_chip.h:343:0: warning: "SG_END" redefined #define SG_END 0x02 In file included from include/linux/blkdev.h:28:0, from drivers/staging/rts5208/rtsx.c:23: include/linux/scatterlist.h:69:0: note: this is the location of the previous definition #define SG_END 0x02UL vim +/SG_END +343 drivers/staging/rts5208/rtsx_chip.h fa590c22 Micky Ching 2013-11-12 340 fa590c22 Micky Ching 2013-11-12 341 /* SG descriptor */ fa590c22 Micky Ching 2013-11-12 342 #define SG_INT0x04 fa590c22 Micky Ching 2013-11-12 @343 #define SG_END0x02 fa590c22 Micky Ching 2013-11-12 344 #define SG_VALID 0x01 fa590c22 Micky Ching 2013-11-12 345 :: The code at line 343 was first introduced by commit :: fa590c222fbaa428edb2ce2194638906cea1400a staging: rts5208: add support for rts5208 and rts5288 :: TO: Micky Ching :: CC: Greg Kroah-Hartman --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH] Support the nonstring variable attribute (gcc >= 8)
>From the GCC manual:
The nonstring variable attribute specifies that an object or member
declaration with type array of char or pointer to char is intended to
store character arrays that do not necessarily contain a terminating NUL
character. This is useful in detecting uses of such arrays or pointers
with functions that expect NUL-terminated strings, and to avoid warnings
when such an array or pointer is used as an argument to a bounded string
manipulation function such as strncpy.
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
Some reports are already coming to the LKML regarding these
warnings. When they are false positives, we can use __nonstring to let
gcc know a NUL character is not required; like in this case:
https://lkml.org/lkml/2018/1/16/135
Signed-off-by: Miguel Ojeda
Cc: Ingo Molnar
Cc: Josh Poimboeuf
Cc: Kees Cook
Cc: Andrew Morton
Cc: Geert Uytterhoeven
Cc: Will Deacon
Cc: Greg Kroah-Hartman
Cc: David Rientjes
---
Another option is using -Wno-stringop-truncation, but it remains to be
seen how useful the new warning will be. We can try to keep it for the
moment until the real bugs and false positives are dealt with and see if
it is worth it.
At least in the reported case at drivers/auxdisplay, using __nonstring
is enough and it can actually replace a comment that was there about the
non-stringness of the char arrays that gcc complained about.
See https://godbolt.org/g/dydPah to play with the warning in this case.
include/linux/compiler-gcc.h | 14 ++
include/linux/compiler_types.h | 4
2 files changed, 18 insertions(+)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 73bc63e0a1c4..6a9784c0c7f3 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -317,6 +317,20 @@
#define __designated_init __attribute__((designated_init))
#endif
+#if GCC_VERSION >= 8
+/*
+ * The nonstring variable attribute specifies that an object or member
+ * declaration with type array of char or pointer to char is intended
+ * to store character arrays that do not necessarily contain a terminating
+ * NUL character. This is useful in detecting uses of such arrays or pointers
+ * with functions that expect NUL-terminated strings, and to avoid warnings
+ * when such an array or pointer is used as an argument to a bounded string
+ * manipulation function such as strncpy.
+ * https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
+ */
+#define __nonstring __attribute__((nonstring))
+#endif
+
#endif /* gcc version >= 4 specific checks */
#if !defined(__noclone)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 6b79a9bba9a7..654dd3114052 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -271,4 +271,8 @@ struct ftrace_likely_data {
# define __native_word(t) (sizeof(t) == sizeof(char) || sizeof(t) ==
sizeof(short) || sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
#endif
+#ifndef __nonstring
+# define __nonstring
+#endif
+
#endif /* __LINUX_COMPILER_TYPES_H */
--
2.14.1
[PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC
From: Sean Wang MediaTek High-Speed DMA controller (HSDMA) on MT7622 and MT7623 SoC has a single ring is dedicated to memory-to-memory transfer through ring based descriptor management. Even though there is only one physical ring available inside HSDMA, the driver can be easily extended to the support of multiple virtual channels processing simultaneously by means of DMA_VIRTUAL_CHANNELS effort. Signed-off-by: Sean Wang Cc: Randy Dunlap Cc: Fengguang Wu Cc: Julia Lawall --- drivers/dma/Kconfig |2 + drivers/dma/Makefile |1 + drivers/dma/mediatek/Kconfig | 13 + drivers/dma/mediatek/Makefile|1 + drivers/dma/mediatek/mtk-hsdma.c | 1054 ++ 5 files changed, 1071 insertions(+) create mode 100644 drivers/dma/mediatek/Kconfig create mode 100644 drivers/dma/mediatek/Makefile create mode 100644 drivers/dma/mediatek/mtk-hsdma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 27df3e2..86ace76 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -633,6 +633,8 @@ config ZX_DMA # driver files source "drivers/dma/bestcomm/Kconfig" +source "drivers/dma/mediatek/Kconfig" + source "drivers/dma/qcom/Kconfig" source "drivers/dma/dw/Kconfig" diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index b9dca8a..7a57b97 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -75,5 +75,6 @@ obj-$(CONFIG_XGENE_DMA) += xgene-dma.o obj-$(CONFIG_ZX_DMA) += zx_dma.o obj-$(CONFIG_ST_FDMA) += st_fdma.o +obj-y += mediatek/ obj-y += qcom/ obj-y += xilinx/ diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig new file mode 100644 index 000..27bac0b --- /dev/null +++ b/drivers/dma/mediatek/Kconfig @@ -0,0 +1,13 @@ + +config MTK_HSDMA + tristate "MediaTek High-Speed DMA controller support" + depends on ARCH_MEDIATEK || COMPILE_TEST + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + ---help--- + Enable support for High-Speed DMA controller on MediaTek + SoCs. + + This controller provides the channels which is dedicated to + memory-to-memory transfer to offload from CPU through ring- + based descriptor management. diff --git a/drivers/dma/mediatek/Makefile b/drivers/dma/mediatek/Makefile new file mode 100644 index 000..6e778f8 --- /dev/null +++ b/drivers/dma/mediatek/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o diff --git a/drivers/dma/mediatek/mtk-hsdma.c b/drivers/dma/mediatek/mtk-hsdma.c new file mode 100644 index 000..a0ae2cc --- /dev/null +++ b/drivers/dma/mediatek/mtk-hsdma.c @@ -0,0 +1,1054 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Driver for MediaTek High-Speed DMA Controller + * + * Copyright (c) 2017-2018 MediaTek Inc. + * Author: Sean Wang + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../virt-dma.h" + +#define MTK_DMA_DEV KBUILD_MODNAME + +#define MTK_HSDMA_USEC_POLL20 +#define MTK_HSDMA_TIMEOUT_POLL 20 +#define MTK_HSDMA_DMA_BUSWIDTHS BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED) + +/* The default number of virtual channel */ +#define MTK_HSDMA_NR_VCHANS3 + +/* Only one physical channel supported */ +#define MTK_HSDMA_NR_MAX_PCHANS1 + +/* Macro for physical descriptor (PD) manipulation */ +/* The number of PD which must be 2 of power */ +#define MTK_DMA_SIZE 64 +#define MTK_HSDMA_NEXT_DESP_IDX(x, y) (((x) + 1) & ((y) - 1)) +#define MTK_HSDMA_LAST_DESP_IDX(x, y) (((x) - 1) & ((y) - 1)) +#define MTK_HSDMA_MAX_LEN 0x3f80 +#define MTK_HSDMA_ALIGN_SIZE 4 +#define MTK_HSDMA_PLEN_MASK0x3fff +#define MTK_HSDMA_DESC_PLEN(x) (((x) & MTK_HSDMA_PLEN_MASK) << 16) +#define MTK_HSDMA_DESC_PLEN_GET(x) (((x) >> 16) & MTK_HSDMA_PLEN_MASK) + +/* Registers for underlying ring manipulation */ +#define MTK_HSDMA_TX_BASE 0x0 +#define MTK_HSDMA_TX_CNT 0x4 +#define MTK_HSDMA_TX_CPU 0x8 +#define MTK_HSDMA_TX_DMA 0xc +#define MTK_HSDMA_RX_BASE 0x100 +#define MTK_HSDMA_RX_CNT 0x104 +#define MTK_HSDMA_RX_CPU 0x108 +#define MTK_HSDMA_RX_DMA 0x10c + +/* Registers for global setup */ +#define MTK_HSDMA_GLO 0x204 +#define MTK_HSDMA_GLO_MULTI_DMABIT(10) +#define MTK_HSDMA_TX_WB_DDONE BIT(6) +#define MTK_HSDMA_BURST_64BYTES(0x2 << 4) +#define MTK_HSDMA_GLO_RX_BUSY BIT(3) +#define MTK_HSDMA_GLO_RX_DMA BIT(2) +#define MTK_HSDMA_GLO_TX_BUSY BIT(1) +#define MTK_HSDMA_GLO_TX_DMA BIT(0) +#define MTK_HSDMA_GLO_DMA (MTK_HSDMA_GLO_TX_DMA | \ +MTK_HSDMA_GLO_RX_D
[PATCH v5 1/3] dt-bindings: dmaengine: Add MediaTek High-Speed DMA controller bindings
From: Sean Wang
Document the devicetree bindings for MediaTek High-Speed DMA controller
which could be found on MT7623 SoC or other similar Mediatek SoCs.
Signed-off-by: Sean Wang
---
.../devicetree/bindings/dma/mtk-hsdma.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt
diff --git a/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
new file mode 100644
index 000..4bb31735
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mtk-hsdma.txt
@@ -0,0 +1,33 @@
+MediaTek High-Speed DMA Controller
+==
+
+This device follows the generic DMA bindings defined in dma/dma.txt.
+
+Required properties:
+
+- compatible: Must be one of
+ "mediatek,mt7622-hsdma": for MT7622 SoC
+ "mediatek,mt7623-hsdma": for MT7623 SoC
+- reg: Should contain the register's base address and length.
+- interrupts: Should contain a reference to the interrupt used by this
+ device.
+- clocks: Should be the clock specifiers corresponding to the entry in
+ clock-names property.
+- clock-names: Should contain "hsdma" entries.
+- power-domains: Phandle to the power domain that the device is part of
+- #dma-cells: The length of the DMA specifier, must be <1>. This one cell
+ in dmas property of a client device represents the channel
+ number.
+Example:
+
+hsdma: dma-controller@1b007000 {
+ compatible = "mediatek,mt7623-hsdma";
+ reg = <0 0x1b007000 0 0x1000>;
+ interrupts = ;
+ clocks = <ðsys CLK_ETHSYS_HSDMA>;
+ clock-names = "hsdma";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
+ #dma-cells = <1>;
+ };
+
+DMA clients must use the format described in dma/dma.txt file.
--
2.7.4
[PATCH v5 3/3] dmaengine: mediatek: update MAINTAINERS entry with MediaTek DMA driver
From: Sean Wang I work for MediaTek and maintain SoC targeting to home gateway and also will keep extending and testing the function. Signed-off-by: Sean Wang --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3bdc260..d3c33d7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8785,6 +8785,15 @@ M: Sean Wang S: Maintained F: drivers/media/rc/mtk-cir.c +MEDIATEK DMA DRIVER +M: Sean Wang +L: dmaeng...@vger.kernel.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-media...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: Documentation/devicetree/bindings/dma/mtk-* +F: drivers/dma/mediatek/ + MEDIATEK PMIC LED DRIVER M: Sean Wang S: Maintained -- 2.7.4
[PATCH v5 0/3] add support for Mediatek High-Speed DMA controller on MT7622 and MT7623 SoC
From: Sean Wang Changes since v4: - rebase to 4.16-rc1 - fold back patch 4 and 5 in v4 into the original commit - add the missing header included - fix typo and add more explanation in existing comments - fix the comments with kernel-doc style which uses /** as the begin - begin the multi-line comments with /* Changes since v3: - enhance dt-binding documents based on Rob's comments - make consistent among all comments - perfer ordering declarations longest to shortest - fix warning reported from kbuild test robot - add patch 4 and 5 to keep Fengguang and Julia's effort Changes since v2: - remove extra tasklets and refactor driver for letting descriptors being processed ASAP. - add more comments stating the relevant logic - remove unused macro and variables - change to use the disclaimer with SPDX identifier - add mt7622 support - refine hardware initialization sequence - add tx_status support for DMA_RESIDUE_GRANULARITY_SEGMENT - refine remove handler with killing vc's tasklet Changes since v1: - fix typo in the commit message. - delete status shown in the dt-binding example. This patchset introduces support for MediaTek High-Speed DMA controller (MTK-HSDMA) Currently, the driver is already tested successfully with dmatest module on MT7622 and MT7623 SoC. MTK-HSDMA on MT7622/23 SoC has a single ring which is dedicated for doing memory-to-memory transfer through ring-based descriptor management. Even though there is only a single ring available inside HSDMA, the driver is being extended to the support for multiple virtual channels processing simultaneously by means of DMA_VIRTUAL_CHANNELS. Sean Wang (3): dt-bindings: dmaengine: Add MediaTek High-Speed DMA controller bindings dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC dmaengine: mediatek: update MAINTAINERS entry with MediaTek DMA driver .../devicetree/bindings/dma/mtk-hsdma.txt | 33 + MAINTAINERS|9 + drivers/dma/Kconfig|2 + drivers/dma/Makefile |1 + drivers/dma/mediatek/Kconfig | 13 + drivers/dma/mediatek/Makefile |1 + drivers/dma/mediatek/mtk-hsdma.c | 1054 7 files changed, 1113 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/mtk-hsdma.txt create mode 100644 drivers/dma/mediatek/Kconfig create mode 100644 drivers/dma/mediatek/Makefile create mode 100644 drivers/dma/mediatek/mtk-hsdma.c -- 2.7.4
Regional Liaison Representative
Hello Atsushi Die Casting Co.Ltd is currently looking on expanding is work force by over 80% by contracting companies and individuals to act as a representative irrespective of your profession to help their growing business based in USA/CANADA.If Interested please send your resume/contact details for immediate consideration via email:atsushidiecast...@gmail.com for details.Note you don't need to pay any money we are the one that will be paying you for your service. Regards, HR Dept
Regional Liaison Representative
Hello Atsushi Die Casting Co.Ltd is currently looking on expanding is work force by over 80% by contracting companies and individuals to act as a representative irrespective of your profession to help their growing business based in USA/CANADA.If Interested please send your resume/contact details for immediate consideration via email:atsushidiecast...@gmail.com for details.Note you don't need to pay any money we are the one that will be paying you for your service. Regards, HR Dept
Regional Liaison Representative
Hello Atsushi Die Casting Co.Ltd is currently looking on expanding is work force by over 80% by contracting companies and individuals to act as a representative irrespective of your profession to help their growing business based in USA/CANADA.If Interested please send your resume/contact details for immediate consideration via email:atsushidiecast...@gmail.com for details.Note you don't need to pay any money we are the one that will be paying you for your service. Regards, HR Dept
Regional Liaison Representative
Hello Atsushi Die Casting Co.Ltd is currently looking on expanding is work force by over 80% by contracting companies and individuals to act as a representative irrespective of your profession to help their growing business based in USA/CANADA.If Interested please send your resume/contact details for immediate consideration via email:atsushidiecast...@gmail.com for details.Note you don't need to pay any money we are the one that will be paying you for your service. Regards, HR Dept
Re: [PATCH V2] lib/scatterlist: Add SG_CHAIN and SG_END macros for LSB encodings
Hi Anshuman, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc1 next-20180216] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/lib-scatterlist-Add-SG_CHAIN-and-SG_END-macros-for-LSB-encodings/20180218-015554 config: i386-randconfig-s0-201807 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): In file included from drivers/misc/cardreader/rtsx_pcr.c:32:0: >> include/linux/rtsx_pci.h:40:0: warning: "SG_END" redefined #define SG_END 0x02 In file included from include/linux/dmapool.h:14:0, from include/linux/pci.h:1316, from drivers/misc/cardreader/rtsx_pcr.c:22: include/linux/scatterlist.h:69:0: note: this is the location of the previous definition #define SG_END 0x02UL vim +/SG_END +40 include/linux/rtsx_pci.h 67d16a46 include/linux/mfd/rtsx_pci.h Wei WANG2012-11-09 37 ada71f55 include/linux/mfd/rtsx_pci.h Micky Ching 2015-02-25 38 #define RTSX_HDBAR0x08 ada71f55 include/linux/mfd/rtsx_pci.h Micky Ching 2015-02-25 39 #define SG_INT 0x04 ada71f55 include/linux/mfd/rtsx_pci.h Micky Ching 2015-02-25 @40 #define SG_END 0x02 ada71f55 include/linux/mfd/rtsx_pci.h Micky Ching 2015-02-25 41 #define SG_VALID0x01 ada71f55 include/linux/mfd/rtsx_pci.h Micky Ching 2015-02-25 42 #define SG_NO_OP0x00 ada71f55 include/linux/mfd/rtsx_pci.h Micky Ching 2015-02-25 43 #define SG_TRANS_DATA (0x02 << 4) ada71f55 include/linux/mfd/rtsx_pci.h Micky Ching 2015-02-25 44 #define SG_LINK_DESC(0x03 << 4) ada71f55 include/linux/mfd/rtsx_pci.h Micky Ching 2015-02-25 45 #define RTSX_HDBCTLR 0x0C 67d16a46 include/linux/mfd/rtsx_pci.h Wei WANG2012-11-09 46 #define SDMA_MODE 0x00 67d16a46 include/linux/mfd/rtsx_pci.h Wei WANG2012-11-09 47 #define ADMA_MODE (0x02 << 26) 67d16a46 include/linux/mfd/rtsx_pci.h Wei WANG2012-11-09 48 #define STOP_DMA(0x01 << 28) 67d16a46 include/linux/mfd/rtsx_pci.h Wei WANG2012-11-09 49 #define TRIG_DMA(0x01 << 31) 67d16a46 include/linux/mfd/rtsx_pci.h Wei WANG2012-11-09 50 :: The code at line 40 was first introduced by commit :: ada71f5588320e7a5c7166cb7c1c8c40cb866ac4 mfd: rtsx: Place register address and values togather :: TO: Micky Ching :: CC: Lee Jones --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 0/2] efivars: reading variables can generate SMIs
On Fri, Feb 16, 2018 at 10:03 PM, Matthew Garrett wrote: > On Fri, Feb 16, 2018 at 2:02 PM Luck, Tony wrote: > >> > If the default is 600 then it makes sense to allow a privileged service > to >> > selectively make certain variables world readable at runtime. > >> As soon as you make one variable world readable you are vulnerable to >> a local user launching a DoS attack by reading that variable over and over >> generating a flood of SMIs. > > I'm not terribly worried about untrusted users on my laptop, but I would > prefer to run as little code as root as possible. I think that, for the most part, systemwide configuration should not be accessible to non-root. Unprivileged users, in general, have no legitimate reason to know that my default boot is Boot* Fedora HD(1,GPT,ee...,0x800,0x64000)/File(\EFI\fedora\shim.efi). Even more so if I'm network booting. Alternatively, we could call this a distro issue. Distros could easily change the permissions on /sys/firmware/efi/efivars to disallow unprivileged access.
Re: [PATCH 4.9 00/92] 4.9.81-stable review
On 02/17/2018 05:45 AM, Greg Kroah-Hartman wrote:
On Sat, Feb 17, 2018 at 02:31:53PM +0100, Yves-Alexis Perez wrote:
On Tue, 2018-02-13 at 16:29 +0100, Greg Kroah-Hartman wrote:
arch/powerpc/kernel/entry_64.S: Assembler messages:
arch/powerpc/kernel/entry_64.S:260: Error: unrecognized opcode: `rfi_to_user'
arch/powerpc/kernel/entry_64.S:270: Error: unrecognized opcode: `rfi_to_kernel'
arch/powerpc/kernel/entry_64.S:885: Error: unrecognized opcode: `rfi_to_user'
arch/powerpc/kernel/entry_64.S:900: Error: unrecognized opcode: `rfi_to_kernel'
Looks like 222f20f140623 ("powerpc/64s: Simple RFI macro conversions") is
missing,
or at least part of it. Unfortunately it doesn't apply cleanly.
Ugh. Let's see if the ppc developers care about this or not :)
Hi,
in Debian we extracted the following hunk from 222f20f140623 to fix build on
powerpc/ppc64el. Only compile tested against Debian builds though.
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 3320bcac7192..e68faa4d1b13 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -37,6 +37,11 @@
#include
#include
#include
+#ifdef CONFIG_PPC_BOOK3S
+#include
+#else
+#include
+#endif
Ah, thanks! I've now queued up this portion of the patch.
Hmm, that chunk really doesn't do what the original patch is supposed to do,
meaning it won't provide the vulnerability protection it is supposed to provide
(AFAICS that is Meltdown). Just a note in case anyone is concerned about
actually providing that protection.
Guenter
Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description
On 02/16/2018 06:00 PM, h...@zytor.com wrote:
> Introducing new, incompatible data formats is an inherently *very*
> costly operation; unfortunately many engineers don't seem to have a good grip
> of just *how* expensive it is (see "silly embedded nonsense hacks", "too
> little, too soon".)
So your argument is we should use the _existing_ cpio format that supports
xattrs?
You keep bringing up the embedded world as a thing you don't understand and is
thus bad. I remember when you dismissed "I would like to constrain my
cross-compiling dependencies to a minimal set" as a... what did you call it, a
silly academic exercise? (Googles...)
https://lkml.org/lkml/2008/2/15/548
> Cpio itself is a great horror show of just how bad this gets:
That's not what you said last time?
http://lkml.iu.edu/hypermail/linux/kernel/0112.2/1540.html
> Introducing a new incompatible data format without strong justification
Here's you suggesting a new format when initramfs first went in, because you
disliked _both_ tar and cpio:
http://lkml.iu.edu/hypermail/linux/kernel/0112.2/1587.html
Seriously, there is a "why cpio rather than tar" section of
https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
with links to the messages. (www.uwsg became lkml in the links, I should submit
a patch fixing that, it redirected 6 months ago...)
We've _had_ this argument already. You are not bringing up _new_ arguments.
This patch set is because people want xattrs in initramfs. I still don't
personally understand why they want this, but they do. We need to still support
the existing file format for the forseeable future, and we might as well fix
y2038 while we're there (treating it as unsigned buys us a lot of decades, but
as long as we're bumping the version number anyway...).
Otherwise it tries to be the minimal set of changes to get us there. (My first
stab at this was dealing with sparse files, but runs of zeroes gzip pretty well
and tmpfs could always make itself sparse after the fact...)
> Doing it under the non-justification of expedience ("oh, we can share most>
> of the code") is aggravated engineering malpractice.
Coming from the guy who added perl as a build dependency to every project he
maintained simultaneously (the linux kernel, your bootloader, klibc), that seems
a lot more like an opinion than an objective metric.
> It is entirely possible that the modern posix tar/pax format is too complex
In the link above you declared it too complex in 2001. Partly because the gnu
tar and pax formats aren't really the same format.
> to be practical in this case – that would be justifying a new format. But
> then you are taking the fundamental cost of breakage, and then the new format
> definitely should not be replicating known defects of another format and
> without at least some thought about how to avoid it in the future.
Didn't Linus flame more than one developer for ripping things out and replacing
them with a new untested thing rather than leaving a trail of breadcrumbs from a
known working thing to another known working thing? Or has the right way to do
it changed since the 2.5 development cycle?
Strangely the poor souls suffering under the burden of cpio to use initramfs
today haven't been screaming out their agony in a detectable way. (They're mad
the kernel doesn't give better feedback about why init failed to launch and it
either paniced or fell through to the fallback ROOT=, my patch to make
devtmpfs_mount work for initramfs was trying to fix the "you pointed the kernel
at a root filesystem directory which it cpio'd up but there was /dev/console in
it so your init has no stdin/stdout/stderr and dies immediately because of it"
problem. And the recent thread about "please don't add a third knob to make
initramfs be tmpfs instead of ramfs" was another corner case of that). And I
have half an INITRAMFS_VERBOSE patch around here somewhere to printk() a lot
more status (and I need to update the initramfs documentation I wrote to help
people have an easier time using it...)
But that's not about archive format. That's kernel userspace bringup being
persnickety. The silent majority you speak for on this archive format issue is
pretty darn silent.
Was this recorded as a problem for you before somebody suggested changing it? I
tend to be public about https://twitter.com/landley/status/964620648050982912
and collect links to other people's concerns when I notice...
Or is this just your opinion?
Rob
Re: [PATCH 3/4] staging: iio: accel: Use sign_extend32 and adjust a switch statement
On Sat, Feb 17, 2018 at 12:23:53PM +, Jonathan Cameron wrote:
> On Mon, 12 Feb 2018 16:10:01 +0300
> Dan Carpenter wrote:
>
> > On Mon, Feb 12, 2018 at 05:24:58PM +0530, Himanshu Jha wrote:
> > > Use sign_extend32 function instead of manually coding it. Also, adjust a
> > ^
> > > switch block to explicitly match channels and return -EINVAL as default
> > > case which improves code readability.
> >
> > Greg likes to say something along the lines of "when you start your
> > sentence with "Also, " that could be a clue that it should be a separate
> > patch.".
> >
> > >
> > > Signed-off-by: Himanshu Jha
> > > ---
> > > drivers/staging/iio/accel/adis16201.c | 13 -
> > > 1 file changed, 8 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/accel/adis16201.c
> > > b/drivers/staging/iio/accel/adis16201.c
> > > index 011d2c5..6800347 100644
> > > --- a/drivers/staging/iio/accel/adis16201.c
> > > +++ b/drivers/staging/iio/accel/adis16201.c
> > > @@ -112,12 +112,17 @@ static int adis16201_read_raw(struct iio_dev
> > > *indio_dev,
> > > case IIO_CHAN_INFO_SCALE:
> > > switch (chan->type) {
> > > case IIO_VOLTAGE:
> > > - if (chan->channel == 0) {
> > > + switch (chan->channel) {
> > > + case 0:
> > > *val = 1;
> > > *val2 = 22;
> > > - } else {
> > > + break;
> > > + case 1:
> > > *val = 0;
> > > *val2 = 61;
> > > + break;
> > > + default:
> > > + return -EINVAL;
> > > }
> >
> > I don't think this improves readability. The -EINVAL is to handle a
> > driver bug which we haven't introduced yet. Probably we would be better
> > off printing a warning or something? But it feels weird to introduce so
> > much code to handle a bug which would actually be pretty difficult to
> > write. The original code is fine.
>
> Hmm. My thought here was that it is not obvious from the code
> that we only have channel 0 and channel 1. The if statement
> kind of implies that channel 0 is special compared to 'all the other'
> elements where as what we are actually doing is picking from
> a set of options. So semantically it's a switch statement being
> implemented as an if else pair ;)
>
> Perhaps we can compromise on the addition of a comment on the else
> case to say it only applies to channel 1?
>
> Dan, what do you think?
>
> It isn't particularly important either way though so feel free to
> just drop this one.
>
To be honest, I dont care either way... The original and the new code
are equivalently clean to me so I have a "leave the code as-is bias" but
if someone else is invested in this code then I like to let the person
who cares the most be the one to decide.
This patch is actually fine but the patch description makes it sound
like it's doing two things. If the subject was
"cleanup adis16201_read_raw()" then that would sound like one thing.
I obviously review thousands of staging patches so some of my responses
are pretty mechanical at this point. If it's a two random things from
the same file then split it into to two patches, but if it's from the
same function that's acceptable.
regards,
dan carpenter
Re: [PATCH 2/3] x86/CPU: Add a microcode loader callback
On Sat, Feb 17, 2018 at 02:28:00PM +0100, Borislav Petkov wrote: > On Sat, Feb 17, 2018 at 05:07:53AM -0800, Raj, Ashok wrote: > > Could you only list it there instead? common.c has no other > > microcode related functions other than this.? > > I already explained that to you: this function is called by the loader > but it uses facilities which are closer to cpu/common.c - get_cpu_cap(), > etc. > > Also, this file will be split eventually after the CPUID cleanup. > > So it could just as well be called recheck_cpu_caps(), without the > "microcode" prefix. Never mind.. now that rings a bell :-) > > So no need to do anything now. >
Re: i2c-designware: sound and s2ram broken on Broadwell-U system since commit ca382f5b38f367b6 (add i2c gpio recovery option)
On Sat, Feb 17, 2018 at 05:09:40PM +0200, Andy Shevchenko wrote:
> On Sat, 2018-02-17 at 17:02 +0200, Andy Shevchenko wrote:
> > On Sat, 2018-02-17 at 14:25 +0100, Dominik Brodowski wrote:
> >
> > > on v4.16-rc1+, sound does not work any more on my Dell XPS 13;
> > > suspend-to-RAM hangs as well. I have bisected this problem down to
> > > commit ca382f5b38f3; reverting this on top of Linus' latest
> > > (1e3510b2b053)
> > > fixes these issues.
> > > And a few snippets from a broken kernel dmesg:
> > >
> > > i2c_designware: probe of INT3432:00 failed with error -38
> > > i2c_designware: probe of INT3433:00 failed with error -38
> >
> > ENOSYS here at probe time, taking into account the commit you think is
> > a
> > culprit, can be passed from gpiod_get() calls only.
> >
> > > Ideas on how to fix this properly?
> >
> > Enable CONFIG_DEBUG_GPIO first and share through some service the
> > dmesg.
> > (it might be good idea to add 'ignore_loglevel initcall_debug' to the
> > kernel command line)
>
> And tell if the following patch helps.
>
> --- a/drivers/i2c/busses/i2c-designware-master.c
> +++ b/drivers/i2c/busses/i2c-designware-master.c
> @@ -644,7 +644,7 @@ static int i2c_dw_init_recovery_info(struct
> dw_i2c_dev *dev)
> gpio = devm_gpiod_get(dev->dev, "scl", GPIOD_OUT_HIGH);
> if (IS_ERR(gpio)) {
> r = PTR_ERR(gpio);
> - if (r == -ENOENT)
> + if (r == -ENOENT || r == -ENOSYS)
> return 0;
> return r;
> }
>
This patch fixes the issue, thanks. Do you still need the DEBUG_GPIO output?
Thanks,
Dominik
Re: [v3,07/11] watchdog/hpwdt: Modify to use watchdog core.
On Thu, Feb 15, 2018 at 04:43:56PM -0700, Jerry Hoemann wrote:
> Follow Documentation/watchdog/convert_drivers_to_kernel_api.txt to
> convert hpwdt from legacy watchdog driver to use the watchdog core.
>
> Removed functions: hpwdt_open, hpwdt_release, hpwdt_write, hpwdt_ioctl
> Removed data structures: hpwdt_fops, hpwdt_miscdev, watchdog_device
> Modified functions: hpwdt_start, hpwdt_stop, hpwdt_ping, hpwdt_gettimeleft
> Added functions: hpwdt_settimeout
> Added structures: watchdog_device
>
> Signed-off-by: Jerry Hoemann
> ---
> drivers/watchdog/hpwdt.c | 249
> ---
> 1 file changed, 63 insertions(+), 186 deletions(-)
>
> diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> index 71e49d0ab789..da9a04101814 100644
> --- a/drivers/watchdog/hpwdt.c
> +++ b/drivers/watchdog/hpwdt.c
> @@ -14,18 +14,13 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> -#include
> -#include
The driver still performs direct IO. Why do you remove this
include file ?
> -#include
> #include
> -#include
> #include
> #include
> #include
> -#include
The PCI vendor IDs used by the driver are declared in this file.
Is there a direction somewhere suggesting that this file
should not be directly included ?
> #include
> -#include
> #include
> +
> #include
>
> #define HPWDT_VERSION"1.4.0"
> @@ -40,8 +35,6 @@ static bool nowayout = WATCHDOG_NOWAYOUT;
> #ifdef CONFIG_HPWDT_NMI_DECODING
> static unsigned int allow_kdump = 1;
> #endif
> -static char expect_release;
> -static unsigned long hpwdt_is_open;
>
> static void __iomem *pci_mem_addr; /* the PCI-memory address */
> static unsigned long __iomem *hpwdt_nmistat;
> @@ -55,53 +48,58 @@ static const struct pci_device_id hpwdt_devices[] = {
> };
> MODULE_DEVICE_TABLE(pci, hpwdt_devices);
>
> +static struct watchdog_device hpwdt_dev;
Please no double declarations. This is only needed for the NMI
code to pass to hpwdt_stop where it isn't used. It would be
easy to introduce _hpwdt_stop() with no parameter and call that
function frm hpwdt_stop().
>
> /*
> * Watchdog operations
> */
> -static void hpwdt_start(void)
> +static int hpwdt_start(struct watchdog_device *dev)
> {
> - reload = SECS_TO_TICKS(soft_margin);
> + reload = SECS_TO_TICKS(dev->timeout);
> +
> iowrite16(reload, hpwdt_timer_reg);
> iowrite8(0x85, hpwdt_timer_con);
> +
> + return 0;
> }
>
> -static void hpwdt_stop(void)
> +static int hpwdt_stop(struct watchdog_device *dev)
> {
> unsigned long data;
>
> data = ioread8(hpwdt_timer_con);
> data &= 0xFE;
> iowrite8(data, hpwdt_timer_con);
> + return 0;
> }
>
> -static void hpwdt_ping(void)
> -{
> - iowrite16(reload, hpwdt_timer_reg);
> -}
> -
> -static int hpwdt_change_timer(int new_margin)
> +static int hpwdt_ping(struct watchdog_device *dev)
> {
> - if (new_margin < 1 || new_margin > HPWDT_MAX_TIMER) {
> - pr_warn("New value passed in is invalid: %d seconds\n",
> - new_margin);
> - return -EINVAL;
> - }
> + reload = SECS_TO_TICKS(dev->timeout);
>
> - soft_margin = new_margin;
> - pr_debug("New timer passed in is %d seconds\n", new_margin);
> - reload = SECS_TO_TICKS(soft_margin);
> + iowrite16(reload, hpwdt_timer_reg);
>
> return 0;
> }
>
> -static int hpwdt_time_left(void)
> +static unsigned int hpwdt_gettimeleft(struct watchdog_device *dev)
> {
> return TICKS_TO_SECS(ioread16(hpwdt_timer_reg));
> }
>
> +static int hpwdt_settimeout(struct watchdog_device *dev, unsigned int val)
> +{
> + dev_dbg(dev->parent, "settimeout = %d\n", val);
> +
> + dev->timeout = val;
> + hpwdt_ping(dev);
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_HPWDT_NMI_DECODING /* { */
> -static int hpwdt_my_nmi(void)
> +
> +static unsigned int hpwdt_my_nmi(void)
> {
> return ioread8(hpwdt_nmistat) & 0x6;
> }
> @@ -123,8 +121,10 @@ static int hpwdt_pretimeout(unsigned int ulReason,
> struct pt_regs *regs)
> if ((ulReason == NMI_UNKNOWN) && !mynmi)
> return NMI_DONE;
>
> + pr_debug("nmi: ulReason=%d, mynmi=0x%0x\n", ulReason, mynmi);
> +
> if (allow_kdump)
> - hpwdt_stop();
> + hpwdt_stop(&hpwdt_dev);
>
> hex_byte_pack(panic_msg, mynmi);
> nmi_panic(regs, panic_msg);
> @@ -133,68 +133,6 @@ static int hpwdt_pretimeout(unsigned int ulReason,
> struct pt_regs *regs)
> }
> #endif /* } */
>
> -/*
> - * /dev/watchdog handling
> - */
> -static int hpwdt_open(struct inode *inode, struct file *file)
> -{
> - /* /dev/watchdog can only be opened once */
> - if (test_and_set_bit(0, &hpwdt_is_open))
> - return -EBUSY;
> -
> - /* Start the watchdog */
> - hpwdt_start();
> - hpwdt_ping();
> -
> - return nonseekable_open(inode, file);
> -
Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
Le 07/02/2018 à 15:39, Horia Geantă a écrit :
On 10/6/2017 4:06 PM, Christophe Leroy wrote:
At every request, we map and unmap the same hash hw_context.
This patch moves the dma mapping/unmapping in functions ahash_init()
and ahash_import().
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 80 ++--
1 file changed, 57 insertions(+), 23 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index ebfd6d982ed6..d495649d5267 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -819,6 +819,7 @@ struct talitos_ctx {
unsigned int keylen;
unsigned int enckeylen;
unsigned int authkeylen;
+ dma_addr_t dma_hw_context;
This doesn't look correct.
talitos_ctx structure is the tfm context.
dma_hw_context is the IOVA of hw_context, located in talitos_ahash_req_ctx
structure (request context).
Yes but I have now found how I can know that the request context is
being released in order to unmap() dma at that time.
It is tricky to use the tmf context I agree, but at least I know when
tmf context get destroyed, ie in talitos_cra_exit_ahash()
The request context is created by ahash_request_alloc() and released by
ahash_request_free(). I have not found the way to call dma_unmap()
before ahash_request_free() gets called.
If there are multiple requests in flight for the same tfm, dma_hw_context will
be overwritten.
Before overwritting dma_hw_context, it is always released, see
talitos_cra_exit_ahash(), ahash_init(), ahash_import()
dma_hw_context needs to be moved in request context (talitos_ahash_req_ctx
struct).
Any suggestion then on how to handle the issue explained above ?
Thanks
Christophe
Thanks,
Horia
[PATCH v2] iio: chemical: ccs811: Corrected firmware boot/application mode transition
CCS811 has different I2C register maps in boot and application mode. When CCS811 is in boot mode, register APP_START (0xF4) is used to transit the firmware state from boot to application mode. However, APP_START is not a valid register location when CCS811 is in application mode (refer to "CCS811 Bootloader Register Map" and "CCS811 Application Register Map" in CCS811 datasheet). The driver should not attempt to perform a write to APP_START while CCS811 is in application mode, as this is not a valid or documented register location. When prob function is being called, the driver assumes the CCS811 sensor is in boot mode, and attempts to perform a write to APP_START. Although CCS811 powers-up in boot mode, it may have already been transited to application mode by previous instances, e.g. unload and reload device driver by the system, or explicitly by user. Depending on the system design, CCS811 sensor may be permanently connected to system power source rather than power controlled by GPIO, hence it is possible that the sensor is never power reset, thus the firmware could be in either boot or application mode at any given time when driver prob function is being called. This patch checks the STATUS register before attempting to send a write to APP_START. Only if the firmware is not in application mode and has valid firmware application loaded, then it will continue to start transiting the firmware boot to application mode. Signed-off-by: Richard Lai --- Changes in v2: - Removed unnecessary macros introduced in previous patch drivers/iio/chemical/ccs811.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/chemical/ccs811.c b/drivers/iio/chemical/ccs811.c index 840a6cb..6ad8a42 100644 --- a/drivers/iio/chemical/ccs811.c +++ b/drivers/iio/chemical/ccs811.c @@ -129,6 +129,9 @@ static int ccs811_start_sensor_application(struct i2c_client *client) if (ret < 0) return ret; + if ((ret & CCS811_STATUS_FW_MODE_APPLICATION)) + return 0; + if ((ret & CCS811_STATUS_APP_VALID_MASK) != CCS811_STATUS_APP_VALID_LOADED) return -EIO; -- 2.7.4
Re: [v3,06/11] watchdog/hpwdt: Select WATCHDOG_CORE
On Thu, Feb 15, 2018 at 04:43:55PM -0700, Jerry Hoemann wrote: > Update Kconfig file to show that hpwdt now selects WATCHDOG_CORE. > > Signed-off-by: Jerry Hoemann At this point, WATCHDOG_CORE is not required. This patch should be merged with the next patch, which adds the requirement. Since it appears that you insist on having it as separate patch, deferring to Wim. Guenter > --- > drivers/watchdog/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 6a602f70aaa4..4d219c3fa8b4 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -1108,6 +1108,7 @@ config IT87_WDT > > config HP_WATCHDOG > tristate "HP ProLiant iLO2+ Hardware Watchdog Timer" > + select WATCHDOG_CORE > depends on X86 && PCI > help > A software monitoring watchdog and NMI sourcing driver. This driver
Re: [v3,05/11] watchdog/hpwdt: Update Module info.
On Thu, Feb 15, 2018 at 04:43:54PM -0700, Jerry Hoemann wrote:
> Update Module Author and description to reflect changes in driver.
>
> Signed-off-by: Jerry Hoemann
> ---
> drivers/watchdog/hpwdt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> index d5989acf3e37..71e49d0ab789 100644
> --- a/drivers/watchdog/hpwdt.c
> +++ b/drivers/watchdog/hpwdt.c
> @@ -425,8 +425,8 @@ static struct pci_driver hpwdt_driver = {
> .remove = hpwdt_exit,
> };
>
> -MODULE_AUTHOR("Tom Mingarelli");
> -MODULE_DESCRIPTION("hp watchdog driver");
> +MODULE_AUTHOR("Jerry Hoemann");
> +MODULE_DESCRIPTION("hpe watchdog driver");
It is quite unusual to replace an author name. The original author is
still the original author and should be retained. Adding another author
is fine, but I disagree with the removal.
Guenter
> MODULE_LICENSE("GPL");
> MODULE_VERSION(HPWDT_VERSION);
>
Re: [PATCH 0/2] efivars: reading variables can generate SMIs
> Would rate limiting (but not only for non-root) help mitigate Spectre > v1 issues in UEFI runtime services code as well? I have been looking > into unmapping the entire kernel while such calls are in progress, > because firmware is likely to remain vulnerable long after the OSes > have been fixed, and we may be able to kill two birds with one stone > here (and not break userland in the process) Yes a global rate limit would seem like a good compromise. -Andi
Re: [v3,04/11] watchdog/hpwdt: white space changes
On Thu, Feb 15, 2018 at 04:43:53PM -0700, Jerry Hoemann wrote:
> Minor white space changes and some name clean up.
>
> Signed-off-by: Jerry Hoemann
> ---
> drivers/watchdog/hpwdt.c | 49
> +++-
> 1 file changed, 23 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> index 07810caabf74..d5989acf3e37 100644
> --- a/drivers/watchdog/hpwdt.c
> +++ b/drivers/watchdog/hpwdt.c
> @@ -1,11 +1,9 @@
> /*
> * HPE WatchDog Driver
> - * based on
> *
> - * SoftDog 0.05: A Software Watchdog Device
> - *
> - * (c) Copyright 2015 Hewlett Packard Enterprise Development LP
> + * (c) Copyright 2018 Hewlett Packard Enterprise Development LP
> * Thomas Mingarelli
> + * Jerry Hoemann
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> @@ -53,7 +51,7 @@ static unsigned long __iomem *hpwdt_timer_con;
> static const struct pci_device_id hpwdt_devices[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, 0xB203) }, /* iLO2 */
> { PCI_DEVICE(PCI_VENDOR_ID_HP, 0x3306) }, /* iLO3 */
> - {0},/* terminate list */
> + {0},/* terminate list */
> };
> MODULE_DEVICE_TABLE(pci, hpwdt_devices);
>
> @@ -102,7 +100,7 @@ static int hpwdt_time_left(void)
> return TICKS_TO_SECS(ioread16(hpwdt_timer_reg));
> }
>
> -#ifdef CONFIG_HPWDT_NMI_DECODING
> +#ifdef CONFIG_HPWDT_NMI_DECODING /* { */
> static int hpwdt_my_nmi(void)
> {
> return ioread8(hpwdt_nmistat) & 0x6;
> @@ -133,7 +131,7 @@ static int hpwdt_pretimeout(unsigned int ulReason, struct
> pt_regs *regs)
>
> return NMI_HANDLED;
> }
> -#endif /* CONFIG_HPWDT_NMI_DECODING */
> +#endif /* } */
I disagree with those changes. While I don't object to adding the '{'
per se, I find it very useful to have the 'CONFIG_HPWDT_NMI_DECODING'
with an endif to be able to associate it with the matching #ifdef.
Deferring to Wim.
Guenter
>
> /*
> * /dev/watchdog handling
> @@ -198,11 +196,11 @@ static ssize_t hpwdt_write(struct file *file, const
> char __user *data,
> return len;
> }
>
> -static const struct watchdog_info ident = {
> - .options = WDIOF_SETTIMEOUT |
> -WDIOF_KEEPALIVEPING |
> -WDIOF_MAGICCLOSE,
> - .identity = "HPE iLO2+ HW Watchdog Timer",
> +static const struct watchdog_info hpwdt_info = {
> + .options= WDIOF_SETTIMEOUT|
> + WDIOF_KEEPALIVEPING |
> + WDIOF_MAGICCLOSE,
> + .identity = "HPE iLO2+ HW Watchdog Timer",
> };
>
> static long hpwdt_ioctl(struct file *file, unsigned int cmd,
> @@ -216,7 +214,7 @@ static long hpwdt_ioctl(struct file *file, unsigned int
> cmd,
> switch (cmd) {
> case WDIOC_GETSUPPORT:
> ret = 0;
> - if (copy_to_user(argp, &ident, sizeof(ident)))
> + if (copy_to_user(argp, &hpwdt_info, sizeof(hpwdt_info)))
> ret = -EFAULT;
> break;
>
> @@ -313,7 +311,7 @@ static int hpwdt_init_nmi_decoding(struct pci_dev *dev)
> return 0;
>
> error2:
> - unregister_nmi_handler(NMI_SERR, "hpwdt");
> + unregister_nmi_handler(NMI_SERR,"hpwdt");
> error1:
> unregister_nmi_handler(NMI_UNKNOWN, "hpwdt");
> error:
> @@ -327,15 +325,14 @@ static int hpwdt_init_nmi_decoding(struct pci_dev *dev)
>
> static void hpwdt_exit_nmi_decoding(void)
> {
> -#ifdef CONFIG_HPWDT_NMI_DECODING
> - unregister_nmi_handler(NMI_UNKNOWN, "hpwdt");
> - unregister_nmi_handler(NMI_SERR, "hpwdt");
> +#ifdef CONFIG_HPWDT_NMI_DECODING /* { */
> + unregister_nmi_handler(NMI_UNKNOWN, "hpwdt");
> + unregister_nmi_handler(NMI_SERR, "hpwdt");
> unregister_nmi_handler(NMI_IO_CHECK, "hpwdt");
> -#endif
> +#endif /* } */
> }
>
> -static int hpwdt_init_one(struct pci_dev *dev,
> - const struct pci_device_id *ent)
> +static int hpwdt_probe(struct pci_dev *dev, const struct pci_device_id *ent)
> {
> int retval;
>
> @@ -422,10 +419,10 @@ static void hpwdt_exit(struct pci_dev *dev)
> }
>
> static struct pci_driver hpwdt_driver = {
> - .name = "hpwdt",
> - .id_table = hpwdt_devices,
> - .probe = hpwdt_init_one,
> - .remove = hpwdt_exit,
> + .name = "hpwdt",
> + .id_table = hpwdt_devices,
> + .probe = hpwdt_probe,
> + .remove = hpwdt_exit,
> };
>
> MODULE_AUTHOR("Tom Mingarelli");
> @@ -440,9 +437,9 @@ module_param(nowayout, bool, 0);
> MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> (default="
> __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
>
> -#ifdef CONFIG_HPWDT_NMI_DECODING
> +#ifdef CONFIG_HPWDT_
