Re: [PATCH] net: ethernet: mediatek: remove useless code in mtk_probe()
Hi, Gustavo
It indeed is useless at the current time point.
but actually I will add new SoC support to the driver in the next week,
which requires the variable match :-(
Sean
On Fri, 2017-07-07 at 15:23 -0500, Gustavo A. R. Silva wrote:
> Remove useless local variables _match_, _soc_ and the code related.
>
> Notice that
>
> const struct of_device_id of_mtk_match[] = {
> { .compatible = "mediatek,mt2701-eth" },
> {},
> };
>
> So match->data is NULL.
>
> Suggested-by: Andrew Lunn
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index adaaafc..b9a5a65 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2401,15 +2401,10 @@ static int mtk_probe(struct platform_device *pdev)
> {
> struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> struct device_node *mac_np;
> - const struct of_device_id *match;
> - struct mtk_soc_data *soc;
> struct mtk_eth *eth;
> int err;
> int i;
>
> - match = of_match_device(of_mtk_match, &pdev->dev);
> - soc = (struct mtk_soc_data *)match->data;
> -
> eth = devm_kzalloc(&pdev->dev, sizeof(*eth), GFP_KERNEL);
> if (!eth)
> return -ENOMEM;
Re: [PATCH v3 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC
On Fri, 2017-07-07 at 09:30 +0200, Jean Delvare wrote:
> Hi Sean,
>
> On ven., 2017-07-07 at 11:56 +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with
> > single cluster and this hardware is also compatible with the existing
> > driver through enabling CPU frequency feature with operating-points-v2
> > bindings. Also, this driver actually supports all MediaTek SoCs, the
> > Kconfig menu entry and file name itself should be updated with more
> > generic name to drop "MT8173"
> >
> > Signed-off-by: Sean Wang
> > Acked-by: Viresh Kumar
> > ---
> > drivers/cpufreq/Kconfig.arm | 8
> > drivers/cpufreq/Makefile| 2 +-
> > drivers/cpufreq/{mt8173-cpufreq.c => mtk-cpufreq.c} | 2 ++
> > 3 files changed, 7 insertions(+), 5 deletions(-)
> > rename drivers/cpufreq/{mt8173-cpufreq.c => mtk-cpufreq.c} (99%)
> >
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index 74ed7e9..79aece7 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -87,14 +87,14 @@ config ARM_KIRKWOOD_CPUFREQ
> > This adds the CPUFreq driver for Marvell Kirkwood
> > SoCs.
> >
> > -config ARM_MT8173_CPUFREQ
> > - tristate "Mediatek MT8173 CPUFreq support"
> > +config ARM_MEDIATEK_CPUFREQ
> > + tristate "CPU Frequency scaling support for MediaTek SoCs"
> > depends on ARCH_MEDIATEK && REGULATOR
> > - depends on ARM64 || (ARM_CPU_TOPOLOGY && COMPILE_TEST)
> > + depends on ARM || ARM64 || COMPILE_TEST
>
> This statement no longer serves any purpose. The whole Kconfig.arm file
> depends on ARM || ARM64, so you can drop it. As a matter of fact no
> other entry in this file has the dependency.
>
Okay, the whole line seemed redundant for that's always true.
I will drop it in the next version.
> > depends on !CPU_THERMAL || THERMAL
> > select PM_OPP
> > help
> > - This adds the CPUFreq driver support for Mediatek MT8173 SoC.
> > + This adds the CPUFreq driver support for MediaTek SoCs.
> >
> > config ARM_OMAP2PLUS_CPUFREQ
> > bool "TI OMAP2+"
> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> > index b7e78f0..4956f5d 100644
> > --- a/drivers/cpufreq/Makefile
> > +++ b/drivers/cpufreq/Makefile
> > @@ -58,7 +58,7 @@ obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) +=
> > exynos5440-cpufreq.o
> > obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
> > obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
> > obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
> > -obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o
> > +obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mtk-cpufreq.o
>
> I would have preferred mediatek-cpufreq. 3-letter abbreviations are
> likely to collide and cause confusion at some point in time. However it
> seems I am late to the party, I see that there are already many files
> named mtk-* or *-mtk.*... So, so be it.
>
> Also the file describing the bindings is named cpufreq-mediatek.txt,
> which is inconsistent... But the situation is the same for a few other
> cpufreq drivers already, so I suppose this is acceptable.
>
Agreed. I also prefer using whole name with mediatek as the
prefix than just abbreviation used. I will update it also in the
next version.
As for the file naming for other drivers, i feel it's okay for me
changing into mediatek as file prefix, but it still depends on
maintainers or original authors if they likes this.
Sean
> > obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
> > obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
> > obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
> > diff --git a/drivers/cpufreq/mt8173-cpufreq.c
> > b/drivers/cpufreq/mtk-cpufreq.c
> > similarity index 99%
> > rename from drivers/cpufreq/mt8173-cpufreq.c
> > rename to drivers/cpufreq/mtk-cpufreq.c
> > index fd1886f..481ec77 100644
> > --- a/drivers/cpufreq/mt8173-cpufreq.c
> > +++ b/drivers/cpufreq/mtk-cpufreq.c
> > @@ -575,6 +575,8 @@ static struct platform_driver mt8173_cpufreq_platdrv = {
> >
> > /* List of machines supported by this driver */
> > static const struct of_device_id mt8173_cpufreq_machines[] __initconst = {
> > + { .compatible = "mediatek,mt2701", },
> > + { .compatible = "mediatek,mt7623", },
> > { .compatible = "mediatek,mt817x", },
> > { .compatible = "mediatek,mt8173", },
> > { .compatible = "mediatek,mt8176", },
>
> Reviewed-by: Jean Delvare
>
Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver (fwd)
Please check on the comparison on line 1489.
julia
-- Forwarded message --
Date: Sat, 8 Jul 2017 10:13:09 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver
Hi Pierre-Yves,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.12 next-20170707]
[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/Pierre-Yves-MORDRET/Add-STM32-MDMA-driver/20170708-013345
:: branch date: 9 hours ago
:: commit date: 9 hours ago
>> drivers/dma/stm32-mdma.c:1489:5-16: WARNING: Unsigned expression compared
>> with zero: dmadev -> irq < 0
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout c6b3687d964d5a49aa0f297918bf26f6cb7444db
vim +1489 drivers/dma/stm32-mdma.c
c6b3687d Pierre-Yves MORDRET 2017-07-06 1473
BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
c6b3687d Pierre-Yves MORDRET 2017-07-06 1474 dd->directions =
BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
c6b3687d Pierre-Yves MORDRET 2017-07-06 1475 BIT(DMA_MEM_TO_MEM);
c6b3687d Pierre-Yves MORDRET 2017-07-06 1476 dd->residue_granularity =
DMA_RESIDUE_GRANULARITY_BURST;
c6b3687d Pierre-Yves MORDRET 2017-07-06 1477 dd->max_burst =
STM32_MDMA_MAX_BURST;
c6b3687d Pierre-Yves MORDRET 2017-07-06 1478 dd->dev = &pdev->dev;
c6b3687d Pierre-Yves MORDRET 2017-07-06 1479 INIT_LIST_HEAD(&dd->channels);
c6b3687d Pierre-Yves MORDRET 2017-07-06 1480
c6b3687d Pierre-Yves MORDRET 2017-07-06 1481 for (i = 0; i <
dmadev->nr_channels; i++) {
c6b3687d Pierre-Yves MORDRET 2017-07-06 1482 chan = &dmadev->chan[i];
c6b3687d Pierre-Yves MORDRET 2017-07-06 1483 chan->id = i;
c6b3687d Pierre-Yves MORDRET 2017-07-06 1484 chan->vchan.desc_free =
stm32_mdma_desc_free;
c6b3687d Pierre-Yves MORDRET 2017-07-06 1485
vchan_init(&chan->vchan, dd);
c6b3687d Pierre-Yves MORDRET 2017-07-06 1486 }
c6b3687d Pierre-Yves MORDRET 2017-07-06 1487
c6b3687d Pierre-Yves MORDRET 2017-07-06 1488 dmadev->irq =
platform_get_irq(pdev, 0);
c6b3687d Pierre-Yves MORDRET 2017-07-06 @1489 if (dmadev->irq < 0) {
c6b3687d Pierre-Yves MORDRET 2017-07-06 1490 dev_err(&pdev->dev,
"failed to get IRQ\n");
c6b3687d Pierre-Yves MORDRET 2017-07-06 1491 return dmadev->irq;
c6b3687d Pierre-Yves MORDRET 2017-07-06 1492 }
c6b3687d Pierre-Yves MORDRET 2017-07-06 1493
c6b3687d Pierre-Yves MORDRET 2017-07-06 1494 ret =
devm_request_irq(&pdev->dev, dmadev->irq, stm32_mdma_irq_handler,
c6b3687d Pierre-Yves MORDRET 2017-07-06 1495 0,
dev_name(&pdev->dev), dmadev);
c6b3687d Pierre-Yves MORDRET 2017-07-06 1496 if (ret) {
c6b3687d Pierre-Yves MORDRET 2017-07-06 1497 dev_err(&pdev->dev,
"failed to request IRQ\n");
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used
Hi Vikram,
On Thu, Jul 6, 2017 at 11:44 PM, Vikram Mulukutla
wrote:
> On 2017-07-04 10:34, Patrick Bellasi wrote:
>>
>> Currently the utilization of the FAIR class is collected before locking
>> the policy. Although that should not be a big issue for most cases, we
>> also don't really know how much latency there can be between the
>> utilization reading and its usage.
>>
>> Let's get the FAIR utilization right before its usage to be better in
>> sync with the current status of a CPU.
>>
>> Signed-off-by: Patrick Bellasi
>> Cc: Ingo Molnar
>> Cc: Peter Zijlstra
>> Cc: Rafael J. Wysocki
>> Cc: Viresh Kumar
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux...@vger.kernel.org
>> ---
>> kernel/sched/cpufreq_schedutil.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/kernel/sched/cpufreq_schedutil.c
>> b/kernel/sched/cpufreq_schedutil.c
>> index 98704d8..df433f1 100644
>> --- a/kernel/sched/cpufreq_schedutil.c
>> +++ b/kernel/sched/cpufreq_schedutil.c
>> @@ -308,10 +308,9 @@ static void sugov_update_shared(struct
>> update_util_data *hook, u64 time,
>> if (unlikely(current == sg_policy->thread))
>> return;
>>
>> - sugov_get_util(&util, &max);
>> -
>> raw_spin_lock(&sg_policy->update_lock);
>>
>> + sugov_get_util(&util, &max);
>> sg_cpu->util = util;
>> sg_cpu->max = max;
>
>
> Given that the utilization update hooks are called with the per-cpu rq lock
> held (for all classes), I don't think PELT utilization can change throughout
> the lifetime of the cpufreq_update_{util,this_cpu} call? Even with Viresh's
> remote cpu callback series we'd still have to hold the rq lock across
> cpufreq_update_util.. what can change today is 'max'
> (arch_scale_cpu_capacity) when a cpufreq policy is shared, so the patch is
> still needed for that reason I think?
>
I didn't follow, Could you elaborate more why you think the patch
helps with the case where max changes while the per-cpu rq lock held?
thanks,
-Joel
Re: [git pull] vfs.git pile 15 - more non-uaccess bits
On Sat, Jul 8, 2017 at 3:30 AM, Al Viro wrote: > Assorted normal VFS / filesystems stuff... > > [this is not all; there are several branches left, but that's for tomorrow] > > The following changes since commit 41f1830f5a7af77cf5c86359aba3cbd706687e52: > > Linux 4.12-rc6 (2017-06-19 22:19:37 +0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc > > for you to fetch changes up to 49d31c2f389acfe83417083e1208422b4091cd9e: > > dentry name snapshots (2017-07-07 20:09:10 -0400) > Al, Do you have a reproducer for reporting wrong names to inotify? If not, do have a recipe I can try to follow to create a reproducer? I would like to add this test to LTP. Incidentally, I got some report on seeing unexpected names reported from my fanotify_sb patches, so I will follow up on that reporrt to verify that your patch fixes the problem. Thanks, Amir.
Re: namei_vfat.c array subscript is above array bounds
> >> > I do not know if this is old or new, just noticed it scrolling by while > >> > compiling current 4.12+git on 32-bit x86. > >> > >> Which version of compiler? > > > > gcc version 6.4.0 20170704 (Debian 6.4.0-1) > > > > After "touch fs/fat/namei_vfat.c" it appears consitently for me. Debian > > unstable, up to date. > > Tried with same gcc version, I can't still reproduce it. Possible > difference is, I'm using x86_64 gcc with ARCH=i386 (-m32). Mine is full 32-bit system. > $ md5sum fs/fat/namei_vfat.c arch/x86/include/asm/string* > d8994e21f6ebc27f89b30a2532b0bc1d fs/fat/namei_vfat.c > e174dd82e3956479e76f2b78ba397287 arch/x86/include/asm/string.h > 662b134b5adb0919ea23e95752a18290 arch/x86/include/asm/string_32.h > b91bcf192dcde29933275f0901e5dac5 arch/x86/include/asm/string_64.h > > Source is same with above? Yes, same checksums. Config: # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.12.0 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_BITS_MAX=16 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_CGROUPS=y # CONFIG_MEMCG is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUP_PIDS is not set # CONFIG_CGROUP_RDMA is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_HUGETLB is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_BPF is not set # CONFIG_CGROUP_DEBUG is not set # CONFIG_SOCK_CGROUP_DATA is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set # CONFIG_SCHED_AUTOGROUP
Re: namei_vfat.c array subscript is above array bounds
Meelis Roos writes: >> > I do not know if this is old or new, just noticed it scrolling by while >> > compiling current 4.12+git on 32-bit x86. >> >> Which version of compiler? > > gcc version 6.4.0 20170704 (Debian 6.4.0-1) > > After "touch fs/fat/namei_vfat.c" it appears consitently for me. Debian > unstable, up to date. Tried with same gcc version, I can't still reproduce it. Possible difference is, I'm using x86_64 gcc with ARCH=i386 (-m32). $ md5sum fs/fat/namei_vfat.c arch/x86/include/asm/string* d8994e21f6ebc27f89b30a2532b0bc1d fs/fat/namei_vfat.c e174dd82e3956479e76f2b78ba397287 arch/x86/include/asm/string.h 662b134b5adb0919ea23e95752a18290 arch/x86/include/asm/string_32.h b91bcf192dcde29933275f0901e5dac5 arch/x86/include/asm/string_64.h Source is same with above? -- OGAWA Hirofumi
Re: [PATCH v16 2/7] power: add power sequence library
On Fri, Jul 07, 2017 at 03:03:06PM +0200, Rafael J. Wysocki wrote:
> On Friday, July 07, 2017 04:01:07 PM Peter Chen wrote:
> > On Fri, Jul 07, 2017 at 03:13:48AM +0200, Rafael J. Wysocki wrote:
> > > >
> > > > - Can I write new code for it or I need to depend on something?
> > >
> > > There is nothing this code needs to depend on AFAICS, but there are
> > > existing
> > > solutions in this problem space (ACPI power management, genpd), so it
> > > needs to
> > > be careful enough about possible overlaps etc.
> > >
> > > > I find there is already "power state" concept at documentation.
> > > > Documentation/ABI/testing/sysfs-devices-power_state
> > >
> > > This is ACPI-specific and only in sysfs directories representing ACPI
> > > device
> > > objects (which aren't physical devices).
> > >
> > > Anyway, since ACPI covers the problem space you are working in already,
> > > your code has to be mutually exclusive with it.
> > >
> > > > - If I can write the new code for it, except the problems I want
> > > > to fix, are there any other use cases I need to consider?
> > >
> > > I would start simple and focus on the particular problem at hand, that is
> > > devices with two power states ("on" and "off") where the "on" state
> > > depends on a number of clocks and/or GPIOs. Still, I'd also avoid making
> > > design choices that might prevent it from being extended in the future
> > > if need be.
> > >
> > > One major problem I can see is how to "attach" the power states framework
> > > to a particular device (once we have discovered that it should be used
> > > with
> > > that device).
> > >
> > > For bus types that don't do power management of their own you could follow
> > > ACPI (and genpd) and provide a PM domain for this purpose, but bus types
> > > doing their own PM (like USB) will probably need to be treated
> > > differently.
> > > In those cases the bus type code will have to know that it should call
> > > some
> > > helpers to switch power states of devices.
> > >
> >
> > After thinking more, using a power state framework is seems too heavy
> > for this use case. This use case is just do some clock and gpio
> > operations before device is created, and do some put operations
> > after device is deleted. We just need some helpers in one structure
> > (called "power sequence" or "power state") for this purpose.
> >
> > For the use case, the clock and gpio operation can be done after device
> > is created, the power domain is more suitable.
>
> There is a problem with PM domains that they only provide hooks for runtime PM
> and system suspend/resume (including hibernation) and not for generic
> "power up" and "power down" operations that may need to be carried out at
> probe time before the runtime PM framework can be used (and analogously
> at remove time).
>
> I would consider starting with the patch below or similar.
>
> Then you can define something like POWER_STATE_SEQUENCE type for your
> case and basically use almost what you have already with it, except that
> struct pwrsec_generic will now become struct power_state_sequence and
> struct power_state_info will be embedded in it instead of struct pwrsec.
>
> The major comceptual difference is that ->power_up and ->power_down are
> now available at the level of the device that needs the power sequence and
> pm_device_power_up/down() can be used wherever necessary (in the code,
> in a bus type, in a controller driver or even in the driver for this
> particular
> device).
Rafeal, thanks for your patch.
The biggest problem for my use case is the device is still not created.
How can I call pm_device_power_up(dev)?
Peter
>
> Most likely you will need a PM domain in addition to that, but mostly to avoid
> code duplication.
>
> And in the future other types of power state definitions may be hooked up
> to that, including ACPI etc.
>
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/base/power/common.c | 35 +++
> include/linux/pm.h | 33 +
> 2 files changed, 68 insertions(+)
>
> Index: linux-pm/include/linux/pm.h
> ===
> --- linux-pm.orig/include/linux/pm.h
> +++ linux-pm/include/linux/pm.h
> @@ -550,6 +550,30 @@ struct pm_subsys_data {
> #endif
> };
>
> +enum power_state_type {
> + POWER_STATE_GENERIC = 0,
> +};
> +
> +/**
> + * struct power_state_info - information related to device power states.
> + *
> + * @type: Power states definition type.
> + * @power_up: Device power up method.
> + * @power_down: Device power down method.
> + *
> + * @power_up is expected to put the device into a power state in which it can
> + * be operated by software (it doesn't have to be the full power state in
> + * principle as long as the device will respond to all software accesses in
> + * this state) and @power_down is expected to put the device into the lowest
> + * power state the device
Re: [PATCH] printk: Move printk_delay to separate file
On Sat, 2017-07-08 at 14:24 +0900, Sergey Senozhatsky wrote: > On (07/07/17 11:08), Joe Perches wrote: > > printk.c is a huge file with too many local functions for a > > human to read and easily parse. > > > > Start to separate out bits into smaller files. > > > > Miscellanea: > > > > o Rename suppress_message_printing to printk_suppress_message > > o Add function definitions to printk.h > > I don't mind, in general, but I'm a bit hesitant. we want to have > automatic printk throttling (printk delay basically) and we need > some of those printk-internal *_seq numbers to see how far consoles > are behind the logbuf. so either we need to 'un-static' those *_seq > and extern them in delay.c or simply keep printk-delay machinery in > printk.c and add the new function. > > // p.s. I'll take a look at the patch a bit later. I'm on a sick leave now. Hey Sergey. Basically, this is a simple trial patch. printk is getting nothing but more complex. I believe printk is in real need of logical separation into multiple parts to isolate the various logic bits. o console o kmsg/devkmsg o logbuf o syslog etc...
[GIT PULL]: dmaengine updates for 4.13-rc1
Hi Linus, Please pull dmaengine updates for v4.13-rc1 as detailed below. The AVR32 removal in dma and sound has been coordinated with me pulling tiwai/topic/avr32-removal into dmaengine tree, you should get those from Takashi. Also the mv_xor fixes ai/topic/avr32-removal is already merged in 4.12 as fixes. The updates are in this request, so diffstat and patches for those don't reflect correctly as this pull is still based on 4.12-rc1. The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-4.13-rc1 for you to fetch changes up to 3edc85023a1e1daf22d8e372c5c4f87dc4a04a71: Merge branch 'topic/rcar' into for-linus (2017-07-04 10:05:22 +0530) dmaengine updates for 4.13-rc1 - removal of AVR32 support in dw driver as AVR32 is gone - new driver for Broadcom stream buffer accelerator (SBA) RAID driver - add support for Faraday Technology FTDMAC020 in amba-pl08x driver - IOMMU support in pl330 driver - updates to bunch of drivers Andy Shevchenko (2): ALSA: atmel: Remove AVR32 bits from the driver dmaengine: dw: Remove AVR32 bits from the driver Anup Patel (4): lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome() dmaengine: Add Broadcom SBA RAID driver dt-bindings: Add DT bindings document for Broadcom SBA RAID driver Arnd Bergmann (1): dmaengine: bcm-sba-raid: fix Kconfig dependencies Arvind Yadav (4): dmaengine: DW DMAC: Handle return value of clk_prepare_enable dmaengine: imx-sdma: Handle return value of clk_prepare_enable dmaengine: imx-sdma: Fix compilation warning. dmaengine: fsl_raid: make of_device_ids const. Colin Ian King (1): dmaengine: bcm-scm-raid: remove redundant null check on req Fabio Estevam (3): dmaengine: mxs: Use %zu for printing a size_t variable dmaengine: Kconfig: Extend the dependency for MXS_DMA dmaengine: Kconfig: Simplify the help text for MXS_DMA Geert Uytterhoeven (1): dt-bindings: rcar-dmac: Document missing error interrupt Hanna Hawa (4): dmaengine: mv_xor_v2: enable XOR engine after its configuration dmaengine: mv_xor_v2: implement proper interrupt coalescing dmaengine: mv_xor_v2: remove unnecessary write to DESQ_STOP register dmaengine: mv_xor_v2: add support for suspend/resume Jon Hunter (1): dmaengine: tegra-apb: Really fix runtime-pm usage Linus Walleij (5): ARM/dmaengine: pl08x: pass reasonable memcpy settings dmaengine: pl08x: Add Faraday FTDMAC020 to compatible list dmaengine: pl08x: Make slave engine optional dmaengine: pl08x: Add support for Faraday Technology FTDMAC020 dmaengine: pl08x: use GENMASK() to create bitmasks Logan Gunthorpe (2): dmaengine: imx-dma: cleanup scatterlist layering violations dmaengine: ste_dma40: Cleanup scatterlist layering violations Matthias Kaehlcke (1): dmaengine: pl330: Delete unused functions Niklas Söderlund (3): dmaengine: rcar-dmac: store channel IRQ in struct rcar_dmac_chan dmaengine: rcar-dmac: implement device_synchronize() dmaengine: rcar-dmac: wait for ISR to finish before freeing resources Prarit Bhargava (1): dmaengine: Replace WARN_TAINT_ONCE() with pr_warn_once() Robin Murphy (1): dmaengine: pl330: Add IOMMU support to slave tranfers Sinan Kaya (2): dmaengine: qcom_hidma: allow ACPI/DT parameters to be overridden dmaengine: qcom_hidma: correct API violation for submit Stefan Roese (1): dmaengine: zynqmp_dma: Remove max len check in zynqmp_dma_prep_memcpy Thomas Breitung (1): dmaengine: fsldma: set BWC, DAHTS and SAHTS values correctly Thomas Petazzoni (6): dmaengine: mv_xor_v2: handle mv_xor_v2_prep_sw_desc() error properly dmaengine: mv_xor_v2: properly handle wrapping in the array of HW descriptors dmaengine: mv_xor_v2: do not use descriptors not acked by async_tx dmaengine: mv_xor_v2: fix tx_submit() implementation dmaengine: mv_xor_v2: remove interrupt coalescing dmaengine: mv_xor_v2: set DMA mask to 40 bits Vinod Koul (7): Merge branch 'topic/bcm' into for-linus Merge branch 'topic/dw' into for-linus Merge branch 'topic/mv_xor' into for-linus Merge branch 'topic/mxs' into for-linus Merge branch 'topic/pl08x' into for-linus Merge branch 'topic/pl330' into for-linus Merge branch 'topic/rcar' into for-linus Wolfram Sang (1): dmaengine: use proper name for the R-Car SoC .../devicetree/bindings/dma/arm-pl08x.txt |9 +- .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 + .../devicetree/bindin
Re: [PATCH 3/9] firmware: arm_scmi: add basic driver infrastructure for SCMI
Hi Roy, Matt, Nishant, Harb Abdulhamid, Loc,
I have a gut feeling you guys were part of the SCMI spec committee. If
so, could you please chime in?
On Fri, Jul 7, 2017 at 11:09 PM, Sudeep Holla wrote:
>
>
> On 07/07/17 17:52, Jassi Brar wrote:
>> Hi Arnd, Hi Rob, Hi Mark,
>>
>> [CC'ing only those who I have the email id of]
>>
>>> +/**
>>> + * scmi_do_xfer() - Do one transfer
>>> + *
>>> + * @info: Pointer to SCMI entity information
>>> + * @xfer: Transfer to initiate and wait for response
>>> + *
>>> + * Return: -ETIMEDOUT in case of no response, if transmit error,
>>> + * return corresponding error, else if all goes well,
>>> + * return 0.
>>> + */
>>> +int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer)
>>> +{
>>> +int ret;
>>> +int timeout;
>>> +struct scmi_info *info = handle_to_scmi_info(handle);
>>> +struct device *dev = info->dev;
>>> +
>>> +ret = mbox_send_message(info->tx_chan, xfer);
>>> +
>>>
>> The api is
>>
>> int mbox_send_message(struct mbox_chan *chan, void *mssg)
>>
>> where each controller driver defines its own format in which it accepts
>> the 'mssg' to be transmitted.
>>
>
> Yes they can continue that, but SCMI just doesn't depend on that.
>
>> For example :-
>> ti_msgmgr_send_data(struct mbox_chan *, struct ti_msgmgr_message *)
>> rockchip_mbox_send_data(struct mbox_chan *, struct rockchip_mbox_msg *)
>> and so on... you get the idea.
>>
>
> Yes I am aware of that.
>
>> Some controller driver may ignore the 'mssg' because only an interrupt line
>> is shared with the remote and not some register/fifo.
>> For example,
>> sti_mbox_send_data(struct mbox_chan *, void *ignored)
>>
>
> Exactly, now with SCMI, every controller *can do* that, as we just care
> about the signaling which in other terms I have so far referred as
> "doorbell".
>
No, the controllers can not ... unless you clone and adapt the 9
drivers+bindings to conform to the expectations of SCMI (like you
attempted with MHU recently). Also, then mandate every future
controller driver must emulate "doorbell" channels.
As the mailbox maintainer, I am open to suggestions that would allow
every controller to support SCMI.
But compared to the options of scmi-as-a-library and
scmi-as-child-node-of-platform-parent, this does not even qualify as
an option.
Why? Because SCMI is but one protocol that provides 4 features ATM,
and certainly can not provide for every whim and quirk of future
platforms. Among the sane requirements are watchdog,
suspend/resume/hibernation and thermal _control_ (not just sensor
readings) and among the weird are video, network and storage over
mailbox api. And even a filesystem backed by read/write over mailbox!!
And these are only that I have worked on first hand.
The point is : you can not assume SCMI to be the only protocol
running over a controller _and_ you can not dictate other protocols to
not touch certain bits of the signal register/fifo.
In simplest terms, controller driver can not cater to only a
particular client. That's the reason we have the controller driver
define the message format and clients conform to it.
Thanks.
Re: [PATCH 2/2] ARM: dts: motorola-cpcap-mapphone: set initial mode for vaudio
* Sebastian Reichel [170707 13:08]: > Set default mode for vaudio, which may be left in standby mode > if the system is booted via kexec from Android. Acked-by: Tony Lindgren
Re: [PATCH 1/2] regulator: cpcap: Fix standby mode
* Sebastian Reichel [170707 13:08]: > While working on the audio-codec I noticed, that the > low power mode of the regulators are not properly > supported. This fixes the issue for vaudio. Yeah good catch: Acked-by: Tony Lindgren
Re: [PATCH 0/3] Motorola Droid 4 Audio Support
* Sebastian Reichel [170707 09:43]: > Hi, > > I got working sound on Droid 4 with mainline \o/. The codec is > currently missing support for detecting if something has been > plugged into the 3.5mm connector, since that seems to require > some closed source firmware and needs further investigation. I > think this can be added later. Hey that's great! I'll give it a try this weekend.. Does that mean that 3G voice calls work too now or is something more needed there? For the CPCAP PMIC macro interrupts I think it's best to set up a separate driver as it seems separate from the core CPCAP functionality. So I think we can just move the unused "cpcap-m2" IRQ banks out of motorola-cpcap.c and put them into a separate child driver that loads it's firmware on init and provides interrupts for the 3.5mm connector. Regards, Tony
Re: [git pull] vfs.git pile 13 - killing __copy_in_user()
On Fri, Jul 7, 2017 at 5:29 PM, Al Viro wrote: > There used to be 6 places in the entire tree calling __copy_in_user(), > all of them bogus. Four got killed off in work.drm branch, this takes care of > the remaining ones and kills the definition of that sucker. This branch is garbage. You seem to have merged in some *old* drm branch into it, so it has all those drm commits that I merged earlier, except they are not the *same* commits. So I'm not pulling this. Ugly duplicate commits and just unnecessary conflicts showing up again. Linus
Re: [PATCH] printk: Move printk_delay to separate file
On (07/07/17 11:08), Joe Perches wrote: > printk.c is a huge file with too many local functions for a > human to read and easily parse. > > Start to separate out bits into smaller files. > > Miscellanea: > > o Rename suppress_message_printing to printk_suppress_message > o Add function definitions to printk.h I don't mind, in general, but I'm a bit hesitant. we want to have automatic printk throttling (printk delay basically) and we need some of those printk-internal *_seq numbers to see how far consoles are behind the logbuf. so either we need to 'un-static' those *_seq and extern them in delay.c or simply keep printk-delay machinery in printk.c and add the new function. // p.s. I'll take a look at the patch a bit later. I'm on a sick leave now. -ss
Re: [PATCH] printk: Modify operators of printed_len
On (07/08/17 10:51), Pierre Kuo wrote:
> In 8b1742c9c207, we remove printk-recursion detection code in
> vprintk_emit(), where it is the first place that printed_len calculated.
> After removing above detection, it seems we can directly assign the
> result of log_output to printed_len.
>
> Signed-off-by: Pierre Kuo
Reviewed-by: Sergey Senozhatsky
-ss
> ---
> kernel/printk/printk.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index fc47863..a2a8cac 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1701,7 +1701,7 @@ asmlinkage int vprintk_emit(int facility, int level,
> size_t text_len = 0;
> enum log_flags lflags = 0;
> unsigned long flags;
> - int printed_len = 0;
> + int printed_len;
> bool in_sched = false;
>
> if (level == LOGLEVEL_SCHED) {
> @@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int level,
> if (dict)
> lflags |= LOG_PREFIX|LOG_NEWLINE;
>
> - printed_len += log_output(facility, level, lflags, dict, dictlen, text,
> text_len);
> + printed_len = log_output(facility, level, lflags, dict, dictlen, text,
> text_len);
>
> logbuf_unlock_irqrestore(flags);
>
> --
> 1.7.9.5
>
Re: [PATCH 2/2] ext4: fix __ext4_new_inode() journal credits calculation
On Wed, Jul 05, 2017 at 07:38:19PM -0700, Tahsin Erdogan wrote:
> ea_inode feature allows creating extended attributes that are up to
> 64k in size. Update __ext4_new_inode() to pick increased credit limits.
>
> To avoid overallocating too many journal credits, update
> __ext4_xattr_set_credits() to make a distinction between xattr create
> vs update. This helps __ext4_new_inode() because all attributes are
> known to be new, so we can save credits that are normally needed to
> delete old values.
>
> Also, have fscrypt specify its maximum context size so that we don't
> end up allocating credits for 64k size.
>
> Signed-off-by: Tahsin Erdogan
I've applied the following change to this patch in order to better
calculate the credits needed by ext4_new_inode. The problem is that
it was estimating a worse case of 287 blocks for ext4_new_inode() on a
10MB file system using the default 1024 block size. And on such a
file system, the typical size of the journal is 1024 blocks, and the
maximum number of credits that are allowed by a handle is 1024 / 4 =
256 blocks. This cases a number of regression tests to blow up.
In reality the SElinux label and EVM/integrity xattrs are never going
to be 64k, so calculating the credits assuming that as the worst case
is not productive. And normally the Posix ACL is never going to be a
worst case of 64k long, either...
- Ted
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 21a2538afcc2..507bfb3344d4 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -784,12 +784,38 @@ struct inode *__ext4_new_inode(handle_t *handle, struct
inode *dir,
}
if (!handle && sbi->s_journal && !(i_flags & EXT4_EA_INODE_FL)) {
- /*
-* 2 ea entries for ext4_init_acl(), 2 for ext4_init_security().
-*/
- nblocks += 4 * __ext4_xattr_set_credits(sb, NULL /* inode */,
- NULL /* block_bh */, XATTR_SIZE_MAX,
+#ifdef CONFIG_EXT4_FS_POSIX_ACL
+ struct posix_acl *p = get_acl(dir, ACL_TYPE_DEFAULT);
+
+ if (p) {
+ int acl_size = p->a_count * sizeof(ext4_acl_entry);
+
+ nblocks += (S_ISDIR(mode) ? 2 : 1) *
+ __ext4_xattr_set_credits(sb, NULL /* inode */,
+ NULL /* block_bh */, acl_size,
+ true /* is_create */);
+ posix_acl_release(p);
+ }
+#endif
+
+#ifdef CONFIG_SECURITY
+ {
+ int num_security_xattrs = 1;
+
+#ifdef CONFIG_INTEGRITY
+ num_security_xattrs++;
+#endif
+ /*
+* We assume that security xattrs are never
+* more than 1k. In practice they are under
+* 128 bytes.
+*/
+ nblocks += num_security_xattrs *
+ __ext4_xattr_set_credits(sb, NULL /* inode */,
+ NULL /* block_bh */, 1024,
true /* is_create */);
+ }
+#endif
if (encrypt)
nblocks += __ext4_xattr_set_credits(sb,
NULL /* inode */, NULL /* block_bh */,
[PATCH] cisco: enic: Fic an error handling path in 'vnic_dev_init_devcmd2()'
if 'ioread32()' returns 0xFFF, we have to go through the error
handling path as done everywhere else in this function.
Move the 'err_free_wq' label to better match its name and its location
and add a new label 'err_disable_wq'.
Update the code accordingly.
Fixes: 373fb0873d43 ("enic: add devcmd2")
Signed-off-by: Christophe JAILLET
---
drivers/net/ethernet/cisco/enic/vnic_dev.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/vnic_dev.c
b/drivers/net/ethernet/cisco/enic/vnic_dev.c
index 1841ad45d215..39bad67422dd 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_dev.c
+++ b/drivers/net/ethernet/cisco/enic/vnic_dev.c
@@ -402,8 +402,8 @@ static int vnic_dev_init_devcmd2(struct vnic_dev *vdev)
fetch_index = ioread32(&vdev->devcmd2->wq.ctrl->fetch_index);
if (fetch_index == 0x) { /* check for hardware gone */
vdev_err(vdev, "Fatal error in devcmd2 init - hardware surprise
removal\n");
-
- return -ENODEV;
+ err = -ENODEV;
+ goto err_free_wq;
}
enic_wq_init_start(&vdev->devcmd2->wq, 0, fetch_index, fetch_index, 0,
@@ -414,7 +414,7 @@ static int vnic_dev_init_devcmd2(struct vnic_dev *vdev)
err = vnic_dev_alloc_desc_ring(vdev, &vdev->devcmd2->results_ring,
DEVCMD2_RING_SIZE, DEVCMD2_DESC_SIZE);
if (err)
- goto err_free_wq;
+ goto err_disable_wq;
vdev->devcmd2->result = vdev->devcmd2->results_ring.descs;
vdev->devcmd2->cmd_ring = vdev->devcmd2->wq.ring.descs;
@@ -433,8 +433,9 @@ static int vnic_dev_init_devcmd2(struct vnic_dev *vdev)
err_free_desc_ring:
vnic_dev_free_desc_ring(vdev, &vdev->devcmd2->results_ring);
-err_free_wq:
+err_disable_wq:
vnic_wq_disable(&vdev->devcmd2->wq);
+err_free_wq:
vnic_wq_free(&vdev->devcmd2->wq);
err_free_devcmd2:
kfree(vdev->devcmd2);
--
2.11.0
Re: [git pull] vfs.git pile 11 - iov_iter/hardening
On Fri, Jul 7, 2017 at 5:29 PM, Al Viro wrote: > > Trivial conflicts with libnvdimm; this stuff will get some > followups, but again, that's for another series. Gaah. Yeah, I guess I could have done the trivial ugly merge that just took the new copy_from_iter_flushcache() as-is, and didn't match it up with all the new iov_iter hardening. Except I decided I don't want that, and want to do a proper merge instead. Which made the trivial merge something that actually changed that copy_from_iter_flushcache() logic, and maybe I screwed it up in the process. It builds, and it looks right to me, but you and Dan should really check out the end result. Particularly so for the CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE logic, which is where this differs from the other cases, and which I changed to make the #ifdef less noticeable. I did try both a i386 and a x86-64 build of the iov_iter code, since that should test both of those ARCH_HAS cases, but that was purely a build test. Also, the new __must_check warnings do trigger. At least for lustre. I couldn't be arsed to try to fix those, since .. lustre. But I'm also adding a couple of lustre people to the cc, just to make them aware of it.. I'd really like the allmodconfig build to be clean. Linus
[RESEND PATCH v2 6/7] pwm: rockchip: Add rk3328 pwm support
The rk3328 soc supports atomic update, we could lock the configuration
of period and duty at first, after unlock is configured, the period and
duty are effective at the same time.
If the polarity, period and duty need to be configured together,
the way for atomic update is "configure lock and old polarity" ->
"configure period and duty" -> "configure unlock and new polarity".
Signed-off-by: David Wu
Acked-by: Rob Herring
---
change in v2:
- 3 different pwm_ops apply(),one for each IP revision.
.../devicetree/bindings/pwm/pwm-rockchip.txt | 1 +
drivers/pwm/pwm-rockchip.c | 63 --
2 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
index 2350ef9..152c736 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: should be "rockchip,-pwm"
"rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs
"rockchip,rk3288-pwm": found on RK3288 SoC
+ "rockchip,rk3328-pwm": found on RK3328 SoC
"rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
- reg: physical base address and length of the controller's registers
- clocks: See ../clock/clock-bindings.txt
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 83703e1..838e8fc 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -29,6 +29,7 @@
#define PWM_INACTIVE_POSITIVE (1 << 4)
#define PWM_POLARITY_MASK (PWM_DUTY_POSITIVE | PWM_INACTIVE_POSITIVE)
#define PWM_OUTPUT_LEFT(0 << 5)
+#define PWM_LOCK_EN(1 << 6)
#define PWM_LP_DISABLE (0 << 8)
struct rockchip_pwm_chip {
@@ -124,13 +125,24 @@ static void rockchip_pwm_get_state(struct pwm_chip *chip,
}
static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- struct pwm_state *state, bool polarity)
+ struct pwm_state *state, bool polarity,
+ bool lock)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
unsigned long period, duty;
u64 clk_rate, div;
u32 ctrl;
+ /*
+* Lock the period and duty of previous configuration, then
+* change the duty and period, that would not be effective.
+*/
+ ctrl = readl_relaxed(pc->base + pc->data->regs.ctrl);
+ if (lock) {
+ ctrl |= PWM_LOCK_EN;
+ writel_relaxed(ctrl, pc->base + pc->data->regs.ctrl);
+ }
+
clk_rate = clk_get_rate(pc->clk);
/*
@@ -148,7 +160,6 @@ static int rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(period, pc->base + pc->data->regs.period);
writel(duty, pc->base + pc->data->regs.duty);
- ctrl = readl_relaxed(pc->base + pc->data->regs.ctrl);
if (polarity) {
ctrl &= ~PWM_POLARITY_MASK;
if (state->polarity == PWM_POLARITY_INVERSED)
@@ -156,6 +167,15 @@ static int rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
else
ctrl |= PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
}
+
+ /*
+* Unlock and set polarity at the same time,
+* the configuration of duty, period and polarity
+* would be effective together at next period.
+*/
+ if (lock)
+ ctrl &= ~PWM_LOCK_EN;
+
writel(ctrl, pc->base + pc->data->regs.ctrl);
return 0;
@@ -209,7 +229,7 @@ static int rockchip_pwm_apply_v1(struct pwm_chip *chip,
struct pwm_device *pwm,
enabled = false;
}
- rockchip_pwm_config(chip, pwm, state, false);
+ rockchip_pwm_config(chip, pwm, state, false, false);
if (state->enabled != enabled)
ret = rockchip_pwm_enable(chip, pwm, state->enabled,
enable_conf);
@@ -236,7 +256,27 @@ static int rockchip_pwm_apply_v2(struct pwm_chip *chip,
struct pwm_device *pwm,
enabled = false;
}
- rockchip_pwm_config(chip, pwm, state, true);
+ rockchip_pwm_config(chip, pwm, state, true, false);
+ if (state->enabled != enabled)
+ ret = rockchip_pwm_enable(chip, pwm, state->enabled,
+ enable_conf);
+
+ return ret;
+}
+
+static int rockchip_pwm_apply_v3(struct pwm_chip *chip, struct pwm_device *pwm,
+struct pwm_state *state)
+{
+ u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
+ PWM_CONTINUOUS;
+ struct pwm_state curstate;
+ bool enabled;
+ int ret = 0;
+
+ pwm_get_state(pwm, &curstate);
+ enabled = curstate.enabled;
+
+ rockchip_pwm_
[PATCH v2 7/7] arm64: dts: rockchip: Add pwm nodes for rk3328
There are 4 pwm channels built in rk3328 soc, need to configure
the both APB clock and bus clock.
Signed-off-by: David Wu
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 45
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 29b3800..46f0847 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -310,6 +310,51 @@
interrupts = ;
};
+ pwm0: pwm@ff1b {
+ compatible = "rockchip,rk3328-pwm";
+ reg = <0x0 0xff1b 0x0 0x10>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
+ clock-names = "pwm", "pclk";
+ status = "disabled";
+ };
+
+ pwm1: pwm@ff1b0010 {
+ compatible = "rockchip,rk3328-pwm";
+ reg = <0x0 0xff1b0010 0x0 0x10>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm1_pin>;
+ clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
+ clock-names = "pwm", "pclk";
+ status = "disabled";
+ };
+
+ pwm2: pwm@ff1b0020 {
+ compatible = "rockchip,rk3328-pwm";
+ reg = <0x0 0xff1b0020 0x0 0x10>;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2_pin>;
+ clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
+ clock-names = "pwm", "pclk";
+ status = "disabled";
+ };
+
+ pwm3: pwm@ff1b0030 {
+ compatible = "rockchip,rk3328-pwm";
+ reg = <0x0 0xff1b0030 0x0 0x10>;
+ interrupts = ;
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwmir_pin>;
+ clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
+ clock-names = "pwm", "pclk";
+ status = "disabled";
+ };
+
saradc: adc@ff28 {
compatible = "rockchip,rk3328-saradc", "rockchip,rk3399-saradc";
reg = <0x0 0xff28 0x0 0x100>;
--
1.9.1
[PATCH v2 6/7] pwm: rockchip: Add rk3328 pwm support
The rk3328 soc supports atomic update, we could lock the configuration
of period and duty at first, after unlock is configured, the period and
duty are effective at the same time.
If the polarity, period and duty need to be configured together,
the way for atomic update is "configure lock and old polarity" ->
"configure period and duty" -> "configure unlock and new polarity".
Signed-off-by: David Wu
Acked-by: Rob Herring
---
change in v2:
- 3 different pwm_ops apply(),one for each IP revision.
.../devicetree/bindings/pwm/pwm-rockchip.txt | 1 +
drivers/pwm/pwm-rockchip.c | 63 --
2 files changed, 60 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
index 2350ef9..152c736 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: should be "rockchip,-pwm"
"rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs
"rockchip,rk3288-pwm": found on RK3288 SoC
+ "rockchip,rk3328-pwm": found on RK3328 SoC
"rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
- reg: physical base address and length of the controller's registers
- clocks: See ../clock/clock-bindings.txt
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 83703e1..838e8fc 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -29,6 +29,7 @@
#define PWM_INACTIVE_POSITIVE (1 << 4)
#define PWM_POLARITY_MASK (PWM_DUTY_POSITIVE | PWM_INACTIVE_POSITIVE)
#define PWM_OUTPUT_LEFT(0 << 5)
+#define PWM_LOCK_EN(1 << 6)
#define PWM_LP_DISABLE (0 << 8)
struct rockchip_pwm_chip {
@@ -124,13 +125,24 @@ static void rockchip_pwm_get_state(struct pwm_chip *chip,
}
static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- struct pwm_state *state, bool polarity)
+ struct pwm_state *state, bool polarity,
+ bool lock)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
unsigned long period, duty;
u64 clk_rate, div;
u32 ctrl;
+ /*
+* Lock the period and duty of previous configuration, then
+* change the duty and period, that would not be effective.
+*/
+ ctrl = readl_relaxed(pc->base + pc->data->regs.ctrl);
+ if (lock) {
+ ctrl |= PWM_LOCK_EN;
+ writel_relaxed(ctrl, pc->base + pc->data->regs.ctrl);
+ }
+
clk_rate = clk_get_rate(pc->clk);
/*
@@ -148,7 +160,6 @@ static int rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(period, pc->base + pc->data->regs.period);
writel(duty, pc->base + pc->data->regs.duty);
- ctrl = readl_relaxed(pc->base + pc->data->regs.ctrl);
if (polarity) {
ctrl &= ~PWM_POLARITY_MASK;
if (state->polarity == PWM_POLARITY_INVERSED)
@@ -156,6 +167,15 @@ static int rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
else
ctrl |= PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
}
+
+ /*
+* Unlock and set polarity at the same time,
+* the configuration of duty, period and polarity
+* would be effective together at next period.
+*/
+ if (lock)
+ ctrl &= ~PWM_LOCK_EN;
+
writel(ctrl, pc->base + pc->data->regs.ctrl);
return 0;
@@ -209,7 +229,7 @@ static int rockchip_pwm_apply_v1(struct pwm_chip *chip,
struct pwm_device *pwm,
enabled = false;
}
- rockchip_pwm_config(chip, pwm, state, false);
+ rockchip_pwm_config(chip, pwm, state, false, false);
if (state->enabled != enabled)
ret = rockchip_pwm_enable(chip, pwm, state->enabled,
enable_conf);
@@ -236,7 +256,27 @@ static int rockchip_pwm_apply_v2(struct pwm_chip *chip,
struct pwm_device *pwm,
enabled = false;
}
- rockchip_pwm_config(chip, pwm, state, true);
+ rockchip_pwm_config(chip, pwm, state, true, false);
+ if (state->enabled != enabled)
+ ret = rockchip_pwm_enable(chip, pwm, state->enabled,
+ enable_conf);
+
+ return ret;
+}
+
+static int rockchip_pwm_apply_v3(struct pwm_chip *chip, struct pwm_device *pwm,
+struct pwm_state *state)
+{
+ u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
+ PWM_CONTINUOUS;
+ struct pwm_state curstate;
+ bool enabled;
+ int ret = 0;
+
+ pwm_get_state(pwm, &curstate);
+ enabled = curstate.enabled;
+
+ rockchip_pwm_
[PATCH v2 5/7] pwm: rockchip: Move the configuration of polarity from rockchip_pwm_set_enable() to rockchip_pwm_config()
It is usually possible to configure the polarity, cycle and duty all at once,
so that the polarity and cycle and duty should be binding together. Move it
into rockchip_pwm_config(), as well as prepared for the next atomic update
commit.
Signed-off-by: David Wu
---
drivers/pwm/pwm-rockchip.c | 46 --
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 12e7b4a8..83703e1 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -27,6 +27,7 @@
#define PWM_DUTY_NEGATIVE (0 << 3)
#define PWM_INACTIVE_NEGATIVE (0 << 4)
#define PWM_INACTIVE_POSITIVE (1 << 4)
+#define PWM_POLARITY_MASK (PWM_DUTY_POSITIVE | PWM_INACTIVE_POSITIVE)
#define PWM_OUTPUT_LEFT(0 << 5)
#define PWM_LP_DISABLE (0 << 8)
@@ -122,12 +123,13 @@ static void rockchip_pwm_get_state(struct pwm_chip *chip,
clk_disable(pc->pclk);
}
-static void rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
+static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state, bool polarity)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
unsigned long period, duty;
u64 clk_rate, div;
+ u32 ctrl;
clk_rate = clk_get_rate(pc->clk);
@@ -136,21 +138,32 @@ static void rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
* bits, every possible input period can be obtained using the
* default prescaler value for all practical clock rate values.
*/
- div = clk_rate * period_ns;
+ div = clk_rate * state->period;
period = DIV_ROUND_CLOSEST_ULL(div,
pc->data->prescaler * NSEC_PER_SEC);
- div = clk_rate * duty_ns;
+ div = clk_rate * state->duty_cycle;
duty = DIV_ROUND_CLOSEST_ULL(div, pc->data->prescaler * NSEC_PER_SEC);
writel(period, pc->base + pc->data->regs.period);
writel(duty, pc->base + pc->data->regs.duty);
+
+ ctrl = readl_relaxed(pc->base + pc->data->regs.ctrl);
+ if (polarity) {
+ ctrl &= ~PWM_POLARITY_MASK;
+ if (state->polarity == PWM_POLARITY_INVERSED)
+ ctrl |= PWM_DUTY_NEGATIVE | PWM_INACTIVE_POSITIVE;
+ else
+ ctrl |= PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
+ }
+ writel(ctrl, pc->base + pc->data->regs.ctrl);
+
+ return 0;
}
static int rockchip_pwm_enable(struct pwm_chip *chip,
struct pwm_device *pwm,
bool enable,
-enum pwm_polarity polarity,
u32 enable_conf)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
@@ -163,15 +176,6 @@ static int rockchip_pwm_enable(struct pwm_chip *chip,
return ret;
}
- if (pc->data->supports_polarity) {
- if (polarity == PWM_POLARITY_INVERSED)
- enable_conf |= PWM_DUTY_NEGATIVE |
- PWM_INACTIVE_POSITIVE;
- else
- enable_conf |= PWM_DUTY_POSITIVE |
- PWM_INACTIVE_NEGATIVE;
- }
-
val = readl_relaxed(pc->base + pc->data->regs.ctrl);
if (enable)
@@ -199,17 +203,16 @@ static int rockchip_pwm_apply_v1(struct pwm_chip *chip,
struct pwm_device *pwm,
enabled = curstate.enabled;
if (state->polarity != curstate.polarity && enabled) {
- ret = rockchip_pwm_enable(chip, pwm, false, state->polarity,
- enable_conf);
+ ret = rockchip_pwm_enable(chip, pwm, false, enable_conf);
if (ret)
return ret;
enabled = false;
}
- rockchip_pwm_config(chip, pwm, state->duty_cycle, state->period);
+ rockchip_pwm_config(chip, pwm, state, false);
if (state->enabled != enabled)
ret = rockchip_pwm_enable(chip, pwm, state->enabled,
- state->polarity, enable_conf);
+ enable_conf);
return ret;
}
@@ -227,17 +230,16 @@ static int rockchip_pwm_apply_v2(struct pwm_chip *chip,
struct pwm_device *pwm,
enabled = curstate.enabled;
if (state->polarity != curstate.polarity && enabled) {
- ret = rockchip_pwm_enable(chip, pwm, false, state->polarity,
- enable_conf);
+ ret = rockchip_pwm_enable(chip, pwm, false, enable_conf);
if (ret)
return ret;
enabled = false;
}
- rockchip_pwm_config(chip, pwm, state-
[PATCH v2 4/7] pwm: rockchip: Use pwm_apply instead of the pwm_enable
Drop the custom hook of pwm_enable and implement
pwm_apply_v1 and pwm_apply_v2 instead.
Signed-off-by: David Wu
---
drivers/pwm/pwm-rockchip.c | 141 +
1 file changed, 77 insertions(+), 64 deletions(-)
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 85f9515..12e7b4a8 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -51,11 +51,10 @@ struct rockchip_pwm_data {
bool supports_polarity;
const struct pwm_ops *ops;
- void (*set_enable)(struct pwm_chip *chip,
- struct pwm_device *pwm, bool enable,
- enum pwm_polarity polarity);
void (*get_state)(struct pwm_chip *chip, struct pwm_device *pwm,
struct pwm_state *state);
+ int (*pwm_apply)(struct pwm_chip *chip, struct pwm_device *pwm,
+struct pwm_state *state);
};
static inline struct rockchip_pwm_chip *to_rockchip_pwm_chip(struct pwm_chip
*c)
@@ -63,24 +62,6 @@ static inline struct rockchip_pwm_chip
*to_rockchip_pwm_chip(struct pwm_chip *c)
return container_of(c, struct rockchip_pwm_chip, chip);
}
-static void rockchip_pwm_set_enable_v1(struct pwm_chip *chip,
- struct pwm_device *pwm, bool enable,
- enum pwm_polarity polarity)
-{
- struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
- u32 enable_conf = PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
- u32 val;
-
- val = readl_relaxed(pc->base + pc->data->regs.ctrl);
-
- if (enable)
- val |= enable_conf;
- else
- val &= ~enable_conf;
-
- writel_relaxed(val, pc->base + pc->data->regs.ctrl);
-}
-
static void rockchip_pwm_get_state_v1(struct pwm_chip *chip,
struct pwm_device *pwm,
struct pwm_state *state)
@@ -94,30 +75,6 @@ static void rockchip_pwm_get_state_v1(struct pwm_chip *chip,
state->enabled = true;
}
-static void rockchip_pwm_set_enable_v2(struct pwm_chip *chip,
- struct pwm_device *pwm, bool enable,
- enum pwm_polarity polarity)
-{
- struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
- u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
- PWM_CONTINUOUS;
- u32 val;
-
- if (polarity == PWM_POLARITY_INVERSED)
- enable_conf |= PWM_DUTY_NEGATIVE | PWM_INACTIVE_POSITIVE;
- else
- enable_conf |= PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
-
- val = readl_relaxed(pc->base + pc->data->regs.ctrl);
-
- if (enable)
- val |= enable_conf;
- else
- val &= ~enable_conf;
-
- writel_relaxed(val, pc->base + pc->data->regs.ctrl);
-}
-
static void rockchip_pwm_get_state_v2(struct pwm_chip *chip,
struct pwm_device *pwm,
struct pwm_state *state)
@@ -193,10 +150,12 @@ static void rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
static int rockchip_pwm_enable(struct pwm_chip *chip,
struct pwm_device *pwm,
bool enable,
-enum pwm_polarity polarity)
+enum pwm_polarity polarity,
+u32 enable_conf)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
int ret;
+ u32 val;
if (enable) {
ret = clk_enable(pc->clk);
@@ -204,7 +163,23 @@ static int rockchip_pwm_enable(struct pwm_chip *chip,
return ret;
}
- pc->data->set_enable(chip, pwm, enable, polarity);
+ if (pc->data->supports_polarity) {
+ if (polarity == PWM_POLARITY_INVERSED)
+ enable_conf |= PWM_DUTY_NEGATIVE |
+ PWM_INACTIVE_POSITIVE;
+ else
+ enable_conf |= PWM_DUTY_POSITIVE |
+ PWM_INACTIVE_NEGATIVE;
+ }
+
+ val = readl_relaxed(pc->base + pc->data->regs.ctrl);
+
+ if (enable)
+ val |= enable_conf;
+ else
+ val &= ~enable_conf;
+
+ writel_relaxed(val, pc->base + pc->data->regs.ctrl);
if (!enable)
clk_disable(pc->clk);
@@ -212,37 +187,75 @@ static int rockchip_pwm_enable(struct pwm_chip *chip,
return 0;
}
-static int rockchip_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
- struct pwm_state *state)
+static int rockchip_pwm_apply_v1(struct pwm_chip *chip, struct pwm_device *pwm,
+struct pwm_state *state)
{
- struct rockchip_pwm_chip *pc = to_rockchip_
[PATCH v2 0/7] Add rk3328 pwm support
There are two features of rk3328 pwm module. - PWM APB and function clocks are different. - Add pwm atomic hardware update David Wu (7): pwm: rockchip: Add APB and function both clocks support pwm: rockchip: Remove the judge from return value of pwm_config pwm: rockchip: Remove the dumplicate rockchip_pwm_ops ops pwm: rockchip: Use pwm_apply instead of the pwm_enable pwm: rockchip: Move the configuration of polarity from rockchip_pwm_set_enable() to rockchip_pwm_config() pwm: rockchip: Add rk3328 pwm support arm64: dts: rockchip: Add pwm nodes for rk3328 .../devicetree/bindings/pwm/pwm-rockchip.txt | 9 +- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 45 drivers/pwm/pwm-rockchip.c | 275 ++--- 3 files changed, 236 insertions(+), 93 deletions(-) -- 1.9.1
[PATCH v2 2/7] pwm: rockchip: Remove the judge from return value of pwm_config
It seems the rockchip_pwm_config always returns the result 0,
so remove the judge.
Signed-off-by: David Wu
Acked-by: Boris Brezillon
---
drivers/pwm/pwm-rockchip.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 617824c..cd45f17 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -165,7 +165,7 @@ static void rockchip_pwm_get_state(struct pwm_chip *chip,
clk_disable(pc->pclk);
}
-static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+static void rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
@@ -188,8 +188,6 @@ static int rockchip_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
writel(period, pc->base + pc->data->regs.period);
writel(duty, pc->base + pc->data->regs.duty);
-
- return 0;
}
static int rockchip_pwm_enable(struct pwm_chip *chip,
@@ -236,13 +234,7 @@ static int rockchip_pwm_apply(struct pwm_chip *chip,
struct pwm_device *pwm,
enabled = false;
}
- ret = rockchip_pwm_config(chip, pwm, state->duty_cycle, state->period);
- if (ret) {
- if (enabled != curstate.enabled)
- rockchip_pwm_enable(chip, pwm, !enabled,
- state->polarity);
- goto out;
- }
+ rockchip_pwm_config(chip, pwm, state->duty_cycle, state->period);
if (state->enabled != enabled) {
ret = rockchip_pwm_enable(chip, pwm, state->enabled,
--
1.9.1
[PATCH v2 1/7] pwm: rockchip: Add APB and function both clocks support
New PWM module provides two individual clocks for APB clock
and function clock.
Signed-off-by: David Wu
Acked-by: Rob Herring
---
.../devicetree/bindings/pwm/pwm-rockchip.txt | 8 +++-
drivers/pwm/pwm-rockchip.c | 53 ++
2 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
index b8be3d0..2350ef9 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
@@ -6,7 +6,13 @@ Required properties:
"rockchip,rk3288-pwm": found on RK3288 SoC
"rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
- reg: physical base address and length of the controller's registers
- - clocks: phandle and clock specifier of the PWM reference clock
+ - clocks: See ../clock/clock-bindings.txt
+ - For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399):
+ - There is one clock that's used both to derive the functional clock
+ for the device and as the bus clock.
+ - For newer hardware (rk3328 and future socs): specified by name
+ - "pwm": This is used to derive the functional clock.
+ - "pclk": This is the APB bus clock.
- #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.txt in this directory
for a description of the cell format.
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 744d561..617824c 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -33,6 +33,7 @@
struct rockchip_pwm_chip {
struct pwm_chip chip;
struct clk *clk;
+ struct clk *pclk;
const struct rockchip_pwm_data *data;
void __iomem *base;
};
@@ -145,7 +146,7 @@ static void rockchip_pwm_get_state(struct pwm_chip *chip,
u64 tmp;
int ret;
- ret = clk_enable(pc->clk);
+ ret = clk_enable(pc->pclk);
if (ret)
return;
@@ -161,7 +162,7 @@ static void rockchip_pwm_get_state(struct pwm_chip *chip,
pc->data->get_state(chip, pwm, state);
- clk_disable(pc->clk);
+ clk_disable(pc->pclk);
}
static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -224,7 +225,7 @@ static int rockchip_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
pwm_get_state(pwm, &curstate);
enabled = curstate.enabled;
- ret = clk_enable(pc->clk);
+ ret = clk_enable(pc->pclk);
if (ret)
return ret;
@@ -257,7 +258,7 @@ static int rockchip_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
rockchip_pwm_get_state(chip, pwm, state);
out:
- clk_disable(pc->clk);
+ clk_disable(pc->pclk);
return ret;
}
@@ -328,7 +329,7 @@ static int rockchip_pwm_probe(struct platform_device *pdev)
const struct of_device_id *id;
struct rockchip_pwm_chip *pc;
struct resource *r;
- int ret;
+ int ret, count;
id = of_match_device(rockchip_pwm_dt_ids, &pdev->dev);
if (!id)
@@ -343,13 +344,38 @@ static int rockchip_pwm_probe(struct platform_device
*pdev)
if (IS_ERR(pc->base))
return PTR_ERR(pc->base);
- pc->clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(pc->clk))
- return PTR_ERR(pc->clk);
+ pc->clk = devm_clk_get(&pdev->dev, "pwm");
+ count = of_property_count_strings(pdev->dev.of_node, "clock-names");
+ if (count == 2)
+ pc->pclk = devm_clk_get(&pdev->dev, "pclk");
+ else
+ pc->pclk = pc->clk;
+
+ if (IS_ERR(pc->clk)) {
+ ret = PTR_ERR(pc->clk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Can't get bus clk: %d\n", ret);
+ return ret;
+ }
+
+ if (IS_ERR(pc->pclk)) {
+ ret = PTR_ERR(pc->pclk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Can't get APB clk: %d\n", ret);
+ return ret;
+ }
ret = clk_prepare_enable(pc->clk);
- if (ret)
+ if (ret) {
+ dev_err(&pdev->dev, "Can't prepare enable bus clk: %d\n", ret);
return ret;
+ }
+
+ ret = clk_prepare(pc->pclk);
+ if (ret) {
+ dev_err(&pdev->dev, "Can't prepare APB clk: %d\n", ret);
+ goto err_clk;
+ }
platform_set_drvdata(pdev, pc);
@@ -368,12 +394,20 @@ static int rockchip_pwm_probe(struct platform_device
*pdev)
if (ret < 0) {
clk_unprepare(pc->clk);
dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
+ goto err_pclk;
}
/* Keep the PWM clk enabled if the PWM appears to be up and running. */
if (!pwm_is_enabled(pc->chip.pwms))
clk_disable(pc->clk);
+ return 0;
[PATCH v2 3/7] pwm: rockchip: Remove the dumplicate rockchip_pwm_ops ops
The rockchip_pwm_ops_v1 and rockchip_pwm_ops_v2 ops are the same
struct members, remove one of them.
Signed-off-by: David Wu
---
drivers/pwm/pwm-rockchip.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index cd45f17..85f9515 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -255,13 +255,7 @@ static int rockchip_pwm_apply(struct pwm_chip *chip,
struct pwm_device *pwm,
return ret;
}
-static const struct pwm_ops rockchip_pwm_ops_v1 = {
- .get_state = rockchip_pwm_get_state,
- .apply = rockchip_pwm_apply,
- .owner = THIS_MODULE,
-};
-
-static const struct pwm_ops rockchip_pwm_ops_v2 = {
+static const struct pwm_ops rockchip_pwm_ops = {
.get_state = rockchip_pwm_get_state,
.apply = rockchip_pwm_apply,
.owner = THIS_MODULE,
@@ -275,7 +269,7 @@ static int rockchip_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
.ctrl = 0x0c,
},
.prescaler = 2,
- .ops = &rockchip_pwm_ops_v1,
+ .ops = &rockchip_pwm_ops,
.set_enable = rockchip_pwm_set_enable_v1,
.get_state = rockchip_pwm_get_state_v1,
};
@@ -289,7 +283,7 @@ static int rockchip_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
},
.prescaler = 1,
.supports_polarity = true,
- .ops = &rockchip_pwm_ops_v2,
+ .ops = &rockchip_pwm_ops,
.set_enable = rockchip_pwm_set_enable_v2,
.get_state = rockchip_pwm_get_state_v2,
};
@@ -303,7 +297,7 @@ static int rockchip_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
},
.prescaler = 1,
.supports_polarity = true,
- .ops = &rockchip_pwm_ops_v2,
+ .ops = &rockchip_pwm_ops,
.set_enable = rockchip_pwm_set_enable_v2,
.get_state = rockchip_pwm_get_state_v2,
};
--
1.9.1
Re: [PATCH 0/2] exec: Use sane stack rlimit for setuid exec
On Fri, Jul 7, 2017 at 1:04 PM, Linus Torvalds wrote: > On Fri, Jul 7, 2017 at 12:56 PM, Kees Cook wrote: >> As discussed with Linus and Andy, we need to reset the stack rlimit >> before we do memory layouts when execing a privilege-gaining (e.g. >> setuid) program. This moves security_bprm_secureexec() earlier (with >> required changes), and then lowers the stack limit when appropriate. > > Looks sane to me, and that first patch looks like a nice cleanup > regardless - the old semantics were insane. > > But yes, we should have more people look at this, particular have the > security module people look at that first patch to make sure it is the > right thing to do for their policies, and make sure that everybody's > bprm_secureexec() function actually looks at the creds in the brmp, > not "current" (well, maybe they compare the two, which makes tons of > sense, and which the old placement didn't sanely support). > > It looks like Kees went through the security modules, but having the > people involved double-check is a good good idea. Updated tree here, I'll send the series in email on Monday: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/setuid-rlimits/secureexec This should fix the missed bprm->cred->security and breaks out each step into logical pieces in case we need to sanely bisect. -Kees -- Kees Cook Pixel Security
Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
On Fri, Jul 7, 2017 at 7:04 PM, Casey Leedom wrote: > Okay, thanks for the note Alexander. I'll have to look more closely at > the patch on Monday and try it out on one of the targeted systems to verify > the semantics you describe. > > However, that said, there is no way to tell a priori where a device will > send TLPs. To simply assume that all TLPs will be directed towards the Root > Complex is a big assumption. Only the device and the code controlling it > know where the TLPs will be directed. That's why there are changes required > in the cxgb4 driver. For instance, the code in > drivers/net/ethernet/chelsio./cxgb4/sge.c: t4_sge_alloc_rxq() knows that > it's allocating Free List Buffers in Host Memory and that the RX Queues that > it's allocating in the Hardware will eventually send Ingress Data to those > Free List Buffers. (And similarly for the Free List Buffer Pointer Queue > with respect to DMA Reads from the host.) In that routine we explicitly > configure the Hardware to use/not-use the Relaxed Ordering Attribute via the > FW_IQ_CMD_FL0FETCHRO and FW_IQ_CMD_FL0DATARO flags. Basically we're > conditionally setting them based on the desirability of sending Relaxed > Ordering TLPs to the Root Complex. (And we would perform the same kind of > check for an nVME application ... which brings us to ...) The general idea with this is to keep this simple. In the vast majority of cases the assumption is that a device will be sending data back and forth from system memory. As such the mostly likely thing that any given device will be interacting with is the root complex. By making it so that we disable relaxed ordering if the root complex says we can't support it seems like the simplest and most direct solution to avoid the issue of us sending any requests with relaxed ordering enabled TLPs to the root complex. With that said what we are getting into are subtleties that end up impacting devices that perform peer-to-peer operations and I don't suspect that peer-to-peer is really all that common. Ideally my thought on this is that if there is something in the setup that cannot support relaxed ordering we should be disabling relaxed ordering and then re-enabling it in the drivers that have special peer-to-peer routes that they are aware of. This should help to simplify things for cases such as a function being direct assigned as the configuration space should be passed through to the guest with the relaxed ordering attribute disabled, and that status will be visible to the guest. If we just use the quirk we lose that and it becomes problematic if a function is direct assigned on a system that doesn't support relaxed ordering as the guest has no visibility into the host's quirks. > And what would be the code using these patch APIs to set up a Peer-to-Peer > nVME-style application? In that case we'd need the Chelsio adapter's PCIe > Capability Device Control[Relaxed Ordering Enable] set for the nVME > application ... and we would avoid programming the Chelsio Hardware to use > Relaxed Ordering for TLPs directed at the Root Complex. Thus we would be in > a position where some TLPs being emitted by the device to Peer devices would > have Relaxed Ordering set and some directed at the Root Complex would not. > And the only way for that to work is if the source device's Device > Control[Relaxed Ordering Enable] is set ... Right. I admit this is pushing extra complexity into the driver, but what else would you have us do? The idea here is more of a lock-out tag-out type setup. We go in and disable relaxed ordering on the devices if it isn't safe to send a relaxed ordering TLP to the root complex. We then leave it up to the driver to go through and re-enable it if the driver knows enough about how it works and what kind of transactions it might issue. I'm not saying we have to leave the relaxed ordering bit disabled in the control register. I'm saying we disable it at first, and then leave it up to the device driver to re-enable it if it needs the functionality for something that is other than root-complex based and it knows it can avoid sending the frames to the root complex. Ideally such a driver would also clean up after itself if removed so that it leaves the device in the same state it found it in. Maybe we don't even really need patch 3/3 in this series. If disabling the relaxed ordering bit in the configuration space already disabled relaxed ordering for the entire device then this patch doesn't even really do anything then right? The device takes care of it already for us so we could probably just drop this patch as it currently stands. If that is the case maybe we need to refocus patch 3/3 on re-enabling relaxed ordering for that nVME specific case. That might be beyond the scope of what Ding can handle though, and I am not familiar with the Chelsio hardware either. So that might be something that is best left to you as a follow-up patch. > Finally, setting aside my disagreements w
Re: [PATCH v3] acpi: handle the acpi hotplug schedule error
Hi Rafael,
On Fri, Jul 07, 2017 at 03:16:40PM +0200, Rafael J. Wysocki wrote:
> On Friday, July 07, 2017 02:22:42 PM Lee, Chun-Yi wrote:
> > Kernel should decrements the reference count of acpi device
> > when the scheduling of acpi hotplug work failed, and evaluates
> > _OST to notify BIOS the failure.
> >
> > v3:
> > More simplify the code. (Rafael J. Wysocki)
> >
> > v2:
> > To simplify the code. (Andy Shevchenko)
> >
> > Cc: "Rafael J. Wysocki"
> > Cc: Len Brown
> > Cc: Michal Hocko
> > Reviewed-by: Andy Shevchenko
> > Signed-off-by: "Lee, Chun-Yi"
>
> This has been applied too AFAICS.
>
I saw patches in linux-next.
Thanks for your review.
Joey Lee
> > ---
> > drivers/acpi/bus.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > index 784bda6..9d4fea6 100644
> > --- a/drivers/acpi/bus.c
> > +++ b/drivers/acpi/bus.c
> > @@ -432,11 +432,15 @@ static void acpi_bus_notify(acpi_handle handle, u32
> > type, void *data)
> > (driver->flags & ACPI_DRIVER_ALL_NOTIFY_EVENTS))
> > driver->ops.notify(adev, type);
> >
> > - if (hotplug_event && ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
> > + if (!hotplug_event) {
> > + acpi_bus_put_acpi_device(adev);
> > + return;
> > + }
> > +
> > + if (ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
> > return;
> >
> > acpi_bus_put_acpi_device(adev);
> > - return;
> >
> > err:
> > acpi_evaluate_ost(handle, type, ost_code, NULL);
> >
>
Re: [PATCH v2 3/4] btrfs: Add zstd support
On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote: > On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > > On 7/6/17, 9:32 AM, "Adam Borowski" wrote: > > > Got a reproducible crash on amd64: > > > Thanks for the bug report Adam! I'm looking into the failure, and haven't > > been able to reproduce it yet. I've built my kernel from your tree, and > > I ran your script with the kernel.tar tarball 100 times, but haven't gotten > > a failure yet. > > > I have a few questions to guide my debugging. > > > > - How many cores are you running with? I’ve run the script with 1, 2, and 4 > > cores. > > - Which version of gcc are you using to compile the kernel? I’m using > > gcc-6.2.0-5ubuntu12. > > - Are the failures always in exactly the same place, and does it fail 100% > > of the time or just regularly? > > 6 cores -- all on bare metal. gcc-7.1.0-9. > Lemme try with gcc-6, a different config or in a VM. I've tried the following: * gcc-6, defconfig (+btrfs obviously) * gcc-7, defconfig * gcc-6, my regular config * gcc-7, my regular config * gcc-7, debug + UBSAN + etc * gcc-7, defconfig, qemu-kvm with only 1 core Every build with gcc-7 reproduces the crash, every with gcc-6 does not. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates.
[PATCH] printk: Modify operators of printed_len
In 8b1742c9c207, we remove printk-recursion detection code in
vprintk_emit(), where it is the first place that printed_len calculated.
After removing above detection, it seems we can directly assign the
result of log_output to printed_len.
Signed-off-by: Pierre Kuo
---
kernel/printk/printk.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index fc47863..a2a8cac 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1701,7 +1701,7 @@ asmlinkage int vprintk_emit(int facility, int level,
size_t text_len = 0;
enum log_flags lflags = 0;
unsigned long flags;
- int printed_len = 0;
+ int printed_len;
bool in_sched = false;
if (level == LOGLEVEL_SCHED) {
@@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int level,
if (dict)
lflags |= LOG_PREFIX|LOG_NEWLINE;
- printed_len += log_output(facility, level, lflags, dict, dictlen, text,
text_len);
+ printed_len = log_output(facility, level, lflags, dict, dictlen, text,
text_len);
logbuf_unlock_irqrestore(flags);
--
1.7.9.5
Re: [PATCH] printk: Modify operators of printed_len
hi Joe >> > [] >> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c >> > >> > [] >> > > @@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int >> > > level, >> > > if (dict) >> > > lflags |= LOG_PREFIX|LOG_NEWLINE; >> > > >> > > - printed_len += log_output(facility, level, lflags, dict, dictlen, >> > > text, text_len); >> > > + printed_len = log_output(facility, level, lflags, dict, dictlen, >> > > text, text_len); >> > >> > If this is appropriate, this should also remove the >> > initialization of printed_len and perhaps rename it too. >> >> I cannot quite understand the reason why need to rename. >> printed_len seems meet the meaning we expect for here. > > Verbosity. To me, len would be adequate. > > Anyway, the real point was the declaration of printed_len could > remove the " = 0" as it's now only set once. Got it and I will resend the patch again. Appreciate your kind advice.
Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3
On Fri, Jul 7, 2017 at 3:24 PM, Linus Torvalds wrote: > On Fri, Jul 7, 2017 at 11:57 AM, Kees Cook wrote: >> To avoid pathological stack usage or the need to special-case setuid >> execs, just limit all arg stack usage to at most _STK_LIM / 4 * 3 (6MB). > > Ok, this I think I should just apply, but would prefer to avoid > multi-line complex conditionals around things like this. > > So how about the attached slightly edited version instead? > > I didn't test it (and I'm not really committing it until I get an ack > or two), but it seemed all ObviouslyCorrect(tm). FamousLastWords(tm). > > Comments? That works for me, thanks. Testing showed the same sane results: $ ulimit -s 32768 $ ./args Detected max args size near: 6291023 bytes $ ulimit -s 24576 $ ./args Detected max args size near: 6291022 bytes $ ulimit -s 20480 $ ./args Detected max args size near: 5242448 bytes $ ulimit -s 16384 $ ./args Detected max args size near: 4193871 bytes $ ulimit -s 8192 $ ./args Detected max args size near: 2096719 bytes $ ulimit -s 4096 $ ./args Detected max args size near: 1048143 bytes -Kees -- Kees Cook Pixel Security
Re: [GIT PULL] writeback error handling fixes (pile #2)
On Thu, Jul 6, 2017 at 5:26 AM, Jeff Layton wrote: > > Sorry for the long description, but I think it's important to give good > background here: Thanks, this was what I wanted. Looks good, and pulled - still going through my basic test-builds before getting pushed out. Linus
Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells
On 07/07/2017 07:51 PM, Goldwyn Rodrigues wrote: > > > On 07/04/2017 05:16 PM, Jens Axboe wrote: >> >> Please expedite getting this upstream, asap. >> > > Jens, > > I have posted an updated patch [1] and it is acked by David. Would you > pick it up or should it go through the btrfs tree (or some other tree)? > > [1] https://patchwork.kernel.org/patch/9825813/ I'm fine with either, I just want it to go in asap. I'm sending off a pull Monday. David, up to you. -- Jens Axboe
Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
Okay, thanks for the note Alexander. I'll have to look more closely at the patch on Monday and try it out on one of the targeted systems to verify the semantics you describe. However, that said, there is no way to tell a priori where a device will send TLPs. To simply assume that all TLPs will be directed towards the Root Complex is a big assumption. Only the device and the code controlling it know where the TLPs will be directed. That's why there are changes required in the cxgb4 driver. For instance, the code in drivers/net/ethernet/chelsio./cxgb4/sge.c: t4_sge_alloc_rxq() knows that it's allocating Free List Buffers in Host Memory and that the RX Queues that it's allocating in the Hardware will eventually send Ingress Data to those Free List Buffers. (And similarly for the Free List Buffer Pointer Queue with respect to DMA Reads from the host.) In that routine we explicitly configure the Hardware to use/not-use the Relaxed Ordering Attribute via the FW_IQ_CMD_FL0FETCHRO and FW_IQ_CMD_FL0DATARO flags. Basically we're conditionally setting them based on the desirability of sending Relaxed Ordering TLPs to the Root Complex. (And we would perform the same kind of check for an nVME application ... which brings us to ...) And what would be the code using these patch APIs to set up a Peer-to-Peer nVME-style application? In that case we'd need the Chelsio adapter's PCIe Capability Device Control[Relaxed Ordering Enable] set for the nVME application ... and we would avoid programming the Chelsio Hardware to use Relaxed Ordering for TLPs directed at the Root Complex. Thus we would be in a position where some TLPs being emitted by the device to Peer devices would have Relaxed Ordering set and some directed at the Root Complex would not. And the only way for that to work is if the source device's Device Control[Relaxed Ordering Enable] is set ... Finally, setting aside my disagreements with the patch, we still have the code in the cxgb4 driver which explicitly turns on its own Device Control[Relaxed Ordering Enable] in cxgb4_main.c: enable_pcie_relaxed_ordering(). So the patch is something of a loop if all we're doing is testing our own Relaxed Ordering Enable state ... Casey
Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells
On 07/04/2017 05:16 PM, Jens Axboe wrote: > > Please expedite getting this upstream, asap. > Jens, I have posted an updated patch [1] and it is acked by David. Would you pick it up or should it go through the btrfs tree (or some other tree)? [1] https://patchwork.kernel.org/patch/9825813/ -- Goldwyn
Re: [PATCH] watchdog: stm32_iwdg: constify watchdog_ops structure
On 07/07/2017 05:28 PM, Gustavo A. R. Silva wrote:
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Guenter Roeck
---
drivers/watchdog/stm32_iwdg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index 6c501b7..be64a86 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -140,7 +140,7 @@ static const struct watchdog_info stm32_iwdg_info = {
.identity = "STM32 Independent Watchdog",
};
-static struct watchdog_ops stm32_iwdg_ops = {
+static const struct watchdog_ops stm32_iwdg_ops = {
.owner = THIS_MODULE,
.start = stm32_iwdg_start,
.ping = stm32_iwdg_ping,
Re: [PATCH] watchdog: coh901327_wdt: constify watchdog_ops structure
On 07/07/2017 05:33 PM, Gustavo A. R. Silva wrote:
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Guenter Roeck
---
drivers/watchdog/coh901327_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/coh901327_wdt.c b/drivers/watchdog/coh901327_wdt.c
index 38dd60f0..4410337 100644
--- a/drivers/watchdog/coh901327_wdt.c
+++ b/drivers/watchdog/coh901327_wdt.c
@@ -218,7 +218,7 @@ static const struct watchdog_info coh901327_ident = {
.identity = DRV_NAME,
};
-static struct watchdog_ops coh901327_ops = {
+static const struct watchdog_ops coh901327_ops = {
.owner = THIS_MODULE,
.start = coh901327_start,
.stop = coh901327_stop,
Re: [PATCH] watchdog: stm32_iwdg: constify watchdog_ops structure
On 07/07/2017 05:28 PM, Gustavo A. R. Silva wrote:
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Guenter Roeck
---
drivers/watchdog/stm32_iwdg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index 6c501b7..be64a86 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -140,7 +140,7 @@ static const struct watchdog_info stm32_iwdg_info = {
.identity = "STM32 Independent Watchdog",
};
-static struct watchdog_ops stm32_iwdg_ops = {
+static const struct watchdog_ops stm32_iwdg_ops = {
.owner = THIS_MODULE,
.start = stm32_iwdg_start,
.ping = stm32_iwdg_ping,
Re: [PATCH] watchdog: it87_wdt: constify watchdog_ops structure
On 07/07/2017 05:23 PM, Gustavo A. R. Silva wrote:
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Guenter Roeck
---
drivers/watchdog/it87_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index dd1e7ea..e96faea 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -253,7 +253,7 @@ static const struct watchdog_info ident = {
.identity = WATCHDOG_NAME,
};
-static struct watchdog_ops wdt_ops = {
+static const struct watchdog_ops wdt_ops = {
.owner = THIS_MODULE,
.start = wdt_start,
.stop = wdt_stop,
Re: [PATCH] watchdog: ts72xx_wdt: constify watchdog_ops structure
On 07/07/2017 05:18 PM, Gustavo A. R. Silva wrote:
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Guenter Roeck
---
drivers/watchdog/ts72xx_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/ts72xx_wdt.c b/drivers/watchdog/ts72xx_wdt.c
index 17c25da..811e43c 100644
--- a/drivers/watchdog/ts72xx_wdt.c
+++ b/drivers/watchdog/ts72xx_wdt.c
@@ -112,7 +112,7 @@ static const struct watchdog_info ts72xx_wdt_ident = {
.identity = "TS-72XX WDT",
};
-static struct watchdog_ops ts72xx_wdt_ops = {
+static const struct watchdog_ops ts72xx_wdt_ops = {
.owner = THIS_MODULE,
.start = ts72xx_wdt_start,
.stop = ts72xx_wdt_stop,
[PATCH V3 0/3] Refine numa_emulation
My previous patch "x86/mm/numa: Remove numa_nodemask_from_meminfo()" hits a problem in numa_emulation. The reason is numa_nodes_parsed is not set correctly after emulation. This patch set tries to fix this and also with two code refine. Detailed discussions are in this thread: https://lkml.org/lkml/2017/3/13/1230 and test result is posted : https://lkml.org/lkml/2017/4/10/641 V3: * remote the error branch and split the loop into a function * refine the comment V2: * refresh the change log based on David comments * use nodes_clear() Wei Yang (3): x86/numa_emulation: refine the calculation of max_emu_nid and dfl_phys_nid x86/numa_emulation: assign physnode_mask directly from numa_nodes_parsed x86/numa_emulation: restructures numa_nodes_parsed from emulated nodes arch/x86/mm/numa_emulation.c | 55 ++-- 1 file changed, 32 insertions(+), 23 deletions(-) -- 2.11.0
[PATCH V3 1/3] x86/numa_emulation: refine the calculation of max_emu_nid and dfl_phys_nid
max_emu_nid and dfl_phys_nid is calculated from emu_nid_to_phys[], which is
calculated in split_nodes_xxx_interleave(). From the logic in these
functions, it is assured the emu_nid_to_phys[] has meaningful value if it
return successfully and ensures dfl_phys_nid will get a valid value.
This patch removes the error branch to check invalid dfl_phys_nid and
abstract this part to a function for readability.
Signed-off-by: Wei Yang
---
arch/x86/mm/numa_emulation.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c
index a8f90ce3dedf..a6d55308660f 100644
--- a/arch/x86/mm/numa_emulation.c
+++ b/arch/x86/mm/numa_emulation.c
@@ -280,6 +280,22 @@ static int __init split_nodes_size_interleave(struct
numa_meminfo *ei,
return 0;
}
+int __init setup_emu2phys_nid(int *dfl_phys_nid)
+{
+ int i, max_emu_nid = 0;
+
+ *dfl_phys_nid = NUMA_NO_NODE;
+ for (i = 0; i < ARRAY_SIZE(emu_nid_to_phys); i++) {
+ if (emu_nid_to_phys[i] != NUMA_NO_NODE) {
+ max_emu_nid = i;
+ if (*dfl_phys_nid == NUMA_NO_NODE)
+ *dfl_phys_nid = emu_nid_to_phys[i];
+ }
+ }
+
+ return max_emu_nid;
+}
+
/**
* numa_emulation - Emulate NUMA nodes
* @numa_meminfo: NUMA configuration to massage
@@ -376,19 +392,7 @@ void __init numa_emulation(struct numa_meminfo
*numa_meminfo, int numa_dist_cnt)
* Determine the max emulated nid and the default phys nid to use
* for unmapped nodes.
*/
- max_emu_nid = 0;
- dfl_phys_nid = NUMA_NO_NODE;
- for (i = 0; i < ARRAY_SIZE(emu_nid_to_phys); i++) {
- if (emu_nid_to_phys[i] != NUMA_NO_NODE) {
- max_emu_nid = i;
- if (dfl_phys_nid == NUMA_NO_NODE)
- dfl_phys_nid = emu_nid_to_phys[i];
- }
- }
- if (dfl_phys_nid == NUMA_NO_NODE) {
- pr_warning("NUMA: Warning: can't determine default physical
node, disabling emulation\n");
- goto no_emu;
- }
+ max_emu_nid = setup_emu2phys_nid(&dfl_phys_nid);
/* commit */
*numa_meminfo = ei;
--
2.11.0
[PATCH V3 2/3] x86/numa_emulation: assign physnode_mask directly from numa_nodes_parsed
numa_init() has already called init_func(), which is responsible for
setting numa_nodes_parsed, so use this nodemask instead of re-finding it
when calling numa_emulation().
This patch gets the physnode_mask directly from numa_nodes_parsed. At
the same time, it corrects the comment of these two functions.
Signed-off-by: Wei Yang
Acked-by: David Rientjes
Reviewed-by: Borislav Petkov
---
arch/x86/mm/numa_emulation.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c
index a6d55308660f..80904ede2e7f 100644
--- a/arch/x86/mm/numa_emulation.c
+++ b/arch/x86/mm/numa_emulation.c
@@ -75,13 +75,15 @@ static int __init emu_setup_memblk(struct numa_meminfo *ei,
/*
* Sets up nr_nodes fake nodes interleaved over physical nodes ranging from
addr
- * to max_addr. The return value is the number of nodes allocated.
+ * to max_addr.
+ *
+ * Returns zero on success or negative on error.
*/
static int __init split_nodes_interleave(struct numa_meminfo *ei,
struct numa_meminfo *pi,
u64 addr, u64 max_addr, int nr_nodes)
{
- nodemask_t physnode_mask = NODE_MASK_NONE;
+ nodemask_t physnode_mask = numa_nodes_parsed;
u64 size;
int big;
int nid = 0;
@@ -116,9 +118,6 @@ static int __init split_nodes_interleave(struct
numa_meminfo *ei,
return -1;
}
- for (i = 0; i < pi->nr_blks; i++)
- node_set(pi->blk[i].nid, physnode_mask);
-
/*
* Continue to fill physical nodes with fake nodes until there is no
* memory left on any of them.
@@ -200,13 +199,15 @@ static u64 __init find_end_of_node(u64 start, u64
max_addr, u64 size)
/*
* Sets up fake nodes of `size' interleaved over physical nodes ranging from
- * `addr' to `max_addr'. The return value is the number of nodes allocated.
+ * `addr' to `max_addr'.
+ *
+ * Returns zero on success or negative on error.
*/
static int __init split_nodes_size_interleave(struct numa_meminfo *ei,
struct numa_meminfo *pi,
u64 addr, u64 max_addr, u64 size)
{
- nodemask_t physnode_mask = NODE_MASK_NONE;
+ nodemask_t physnode_mask = numa_nodes_parsed;
u64 min_size;
int nid = 0;
int i, ret;
@@ -231,9 +232,6 @@ static int __init split_nodes_size_interleave(struct
numa_meminfo *ei,
}
size &= FAKE_NODE_MIN_HASH_MASK;
- for (i = 0; i < pi->nr_blks; i++)
- node_set(pi->blk[i].nid, physnode_mask);
-
/*
* Fill physical nodes with fake nodes of size until there is no memory
* left on any of them.
--
2.11.0
[PATCH V3 3/3] x86/numa_emulation: restructures numa_nodes_parsed from emulated nodes
By emulating numa, it may contains more or less nodes than physical nodes. In numa_emulation(), numa_meminfo/numa_distance/__apicid_to_node is restructured according to emulated nodes, except numa_nodes_parsed. This patch restructures numa_nodes_parsed from emulated nodes. Signed-off-by: Wei Yang Acked-by: David Rientjes --- arch/x86/mm/numa_emulation.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c index 80904ede2e7f..d805162e6045 100644 --- a/arch/x86/mm/numa_emulation.c +++ b/arch/x86/mm/numa_emulation.c @@ -395,6 +395,13 @@ void __init numa_emulation(struct numa_meminfo *numa_meminfo, int numa_dist_cnt) /* commit */ *numa_meminfo = ei; + /* Make sure numa_nodes_parsed only contains emulated nodes */ + nodes_clear(numa_nodes_parsed); + for (i = 0; i < ARRAY_SIZE(ei.blk); i++) + if (ei.blk[i].start != ei.blk[i].end && + ei.blk[i].nid != NUMA_NO_NODE) + node_set(ei.blk[i].nid, numa_nodes_parsed); + /* * Transform __apicid_to_node table to use emulated nids by * reverse-mapping phys_nid. The maps should always exist but fall -- 2.11.0
[PATCH] video: cobalt_lcdfb: constify fb_fix_screeninfo structure
This structure is only used to copy into other structures,
so declare it as const.
This issue was detected using Coccinelle and the following semantic patch:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct fb_fix_screeninfo i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct fb_fix_screeninfo e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct fb_fix_screeninfo i = { ... };
Signed-off-by: Gustavo A. R. Silva
---
drivers/video/fbdev/cobalt_lcdfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/cobalt_lcdfb.c
b/drivers/video/fbdev/cobalt_lcdfb.c
index 9da90bd..0ef633e 100644
--- a/drivers/video/fbdev/cobalt_lcdfb.c
+++ b/drivers/video/fbdev/cobalt_lcdfb.c
@@ -126,7 +126,7 @@ static void lcd_clear(struct fb_info *info)
lcd_write_control(info, LCD_RESET);
}
-static struct fb_fix_screeninfo cobalt_lcdfb_fix = {
+static const struct fb_fix_screeninfo cobalt_lcdfb_fix = {
.id = "cobalt-lcd",
.type = FB_TYPE_TEXT,
.type_aux = FB_AUX_TEXT_MDA,
--
2.5.0
[PATCH] video: xilinxfb: constify fb_fix_screeninfo and fb_var_screeninfo structures
These structures are only used to copy into other structures,
so declare them as const.
This issue was detected using Coccinelle and the following semantic patch:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct fb_fix_screeninfo i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct fb_fix_screeninfo e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct fb_fix_screeninfo i = { ... };
The semantic patch for fb_var_screeninfo is analogous.
Signed-off-by: Gustavo A. R. Silva
---
drivers/video/fbdev/xilinxfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/xilinxfb.c b/drivers/video/fbdev/xilinxfb.c
index 17dc119..0bda18e 100644
--- a/drivers/video/fbdev/xilinxfb.c
+++ b/drivers/video/fbdev/xilinxfb.c
@@ -110,14 +110,14 @@ static struct xilinxfb_platform_data
xilinx_fb_default_pdata = {
/*
* Here are the default fb_fix_screeninfo and fb_var_screeninfo structures
*/
-static struct fb_fix_screeninfo xilinx_fb_fix = {
+static const struct fb_fix_screeninfo xilinx_fb_fix = {
.id = "Xilinx",
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_TRUECOLOR,
.accel =FB_ACCEL_NONE
};
-static struct fb_var_screeninfo xilinx_fb_var = {
+static const struct fb_var_screeninfo xilinx_fb_var = {
.bits_per_pixel = BITS_PER_PIXEL,
.red = { RED_SHIFT, 8, 0 },
--
2.5.0
[PATCH] video/chips: constify fb_fix_screeninfo and fb_var_screeninfo structures
These structures are only used to copy into other structures,
so declare them as const.
This issue was detected using Coccinelle and the following semantic patch:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct fb_fix_screeninfo i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct fb_fix_screeninfo e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct fb_fix_screeninfo i = { ... };
The semantic patch for fb_var_screeninfo is analogous.
Signed-off-by: Gustavo A. R. Silva
---
drivers/video/fbdev/chipsfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/chipsfb.c b/drivers/video/fbdev/chipsfb.c
index 59abdc6..f103665 100644
--- a/drivers/video/fbdev/chipsfb.c
+++ b/drivers/video/fbdev/chipsfb.c
@@ -292,7 +292,7 @@ static void chips_hw_init(void)
write_fr(chips_init_fr[i].addr, chips_init_fr[i].data);
}
-static struct fb_fix_screeninfo chipsfb_fix = {
+static const struct fb_fix_screeninfo chipsfb_fix = {
.id = "C&T 65550",
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_PSEUDOCOLOR,
@@ -309,7 +309,7 @@ static struct fb_fix_screeninfo chipsfb_fix = {
.smem_len = 0x10, /* 1MB */
};
-static struct fb_var_screeninfo chipsfb_var = {
+static const struct fb_var_screeninfo chipsfb_var = {
.xres = 800,
.yres = 600,
.xres_virtual = 800,
--
2.5.0
Re: [PATCH v5 3/5] mtd: handle partitioning on devices with 0 erasesize
On Tue, Jul 04, 2017 at 03:22:52AM +, Chris Packham wrote: > I had someone mention to me in passing that mtdinfo was failing for them > (crashing with some floating point error). I'm wondering if we've > created a divide-by-zero problem by reporting 0 erase size in /proc/mtd. > I don't have any other info and right now I don't have access to the > system I had with the mchp23lcv1024 sram. Wouldn't be that surprising. mtdinfo is actually developed under the "ubi-utils" directory of mtd-utils, and UBI wouldn't know what to do with and SRAM like that. Brian
[PATCH] video/mbx: constify fb_fix_screeninfo and fb_var_screeninfo structures
These structures are only used to copy into other structures,
so declare them as const.
This issue was detected using Coccinelle and the following semantic patch:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct fb_fix_screeninfo i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct fb_fix_screeninfo e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct fb_fix_screeninfo i = { ... };
The semantic patch for fb_var_screeninfo is analogous.
Signed-off-by: Gustavo A. R. Silva
---
drivers/video/fbdev/mbx/mbxfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/mbx/mbxfb.c b/drivers/video/fbdev/mbx/mbxfb.c
index 698df954..539b85d 100644
--- a/drivers/video/fbdev/mbx/mbxfb.c
+++ b/drivers/video/fbdev/mbx/mbxfb.c
@@ -79,7 +79,7 @@ struct mbxfb_info {
};
-static struct fb_var_screeninfo mbxfb_default = {
+static const struct fb_var_screeninfo mbxfb_default = {
.xres = 640,
.yres = 480,
.xres_virtual = 640,
@@ -102,7 +102,7 @@ static struct fb_var_screeninfo mbxfb_default = {
.sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
};
-static struct fb_fix_screeninfo mbxfb_fix = {
+static const struct fb_fix_screeninfo mbxfb_fix = {
.id = "MBX",
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_TRUECOLOR,
--
2.5.0
[GIT PULL] MD update for 4.13
Hi,
Please pull MD update for 4.13. This update only includes several bug fixes:
- Neil Brown fixes a deadlock in MD suspend and a potential bug in bio
allocation.
- Mikulas Patocka fixes a signal issue
- Guoqing Jiang fixes a typo in FailFast test
- Other trival fixes
Please note, there is a merge conflict with block tree and causes build error,
which could be fixed by this one:
diff --git a/drivers/md/md.c b/drivers/md/md.c
index c4d41b03324b..8cdca0296749 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5450,7 +5450,7 @@ int md_run(struct mddev *mddev)
return -ENOMEM;
}
if (mddev->sync_set == NULL) {
- mddev->sync_set = bioset_create(BIO_POOL_SIZE, 0);
+ mddev->sync_set = bioset_create(BIO_POOL_SIZE, 0,
BIOSET_NEED_BVECS);
if (!mddev->sync_set)
return -ENOMEM;
}
Thanks,
Shaohua
The following changes since commit 63f700aab4c11d46626de3cd051dae56cf7e9056:
Merge tag 'xtensa-20170612' of git://github.com/jcmvbkbc/linux-xtensa
(2017-06-13 15:09:10 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git for-next
for you to fetch changes up to 7184ef8bab0cb865c3cea9dd1a675771145df0af:
MD: fix sleep in atomic (2017-07-03 14:38:59 -0700)
Guoqing Jiang (2):
md/raid10: fix FailFast test for wrong device
md/raid1: remove unused bio in sync_request_write
Lidong Zhong (1):
md: change the initialization value for a spare device spot to
MD_DISK_ROLE_SPARE
Mikulas Patocka (1):
md: don't use flush_signals in userspace processes
NeilBrown (2):
md: fix deadlock between mddev_suspend() and md_write_start()
md: use a separate bio_set for synchronous IO.
Shaohua Li (2):
MD: fix a null dereference
MD: fix sleep in atomic
drivers/md/faulty.c| 5 +++--
drivers/md/linear.c| 7 ---
drivers/md/md.c| 47 ++-
drivers/md/md.h| 7 +--
drivers/md/multipath.c | 8
drivers/md/raid0.c | 7 ---
drivers/md/raid1.c | 20
drivers/md/raid10.c| 16 +---
drivers/md/raid5.c | 22 +-
9 files changed, 92 insertions(+), 47 deletions(-)
[PATCH] auxdisplay: cfag12864bfb: constify fb_fix_screeninfo and fb_var_screeninfo structures
These structures are only used to copy into other structures,
so declare them as const.
This issue was detected using Coccinelle and the following semantic patch:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct fb_fix_screeninfo i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct fb_fix_screeninfo e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct fb_fix_screeninfo i = { ... };
The semantic patch for fb_var_screeninfo is analogous.
Signed-off-by: Gustavo A. R. Silva
---
drivers/auxdisplay/cfag12864bfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/auxdisplay/cfag12864bfb.c
b/drivers/auxdisplay/cfag12864bfb.c
index a387403..dcbee7e 100644
--- a/drivers/auxdisplay/cfag12864bfb.c
+++ b/drivers/auxdisplay/cfag12864bfb.c
@@ -37,7 +37,7 @@
#define CFAG12864BFB_NAME "cfag12864bfb"
-static struct fb_fix_screeninfo cfag12864bfb_fix = {
+static const struct fb_fix_screeninfo cfag12864bfb_fix = {
.id = "cfag12864b",
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_MONO10,
@@ -48,7 +48,7 @@ static struct fb_fix_screeninfo cfag12864bfb_fix = {
.accel = FB_ACCEL_NONE,
};
-static struct fb_var_screeninfo cfag12864bfb_var = {
+static const struct fb_var_screeninfo cfag12864bfb_var = {
.xres = CFAG12864B_WIDTH,
.yres = CFAG12864B_HEIGHT,
.xres_virtual = CFAG12864B_WIDTH,
--
2.5.0
Re: [Xen-devel] maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"
On Tue, Mar 28, 2017 at 05:30:24PM +0200, Juergen Gross wrote: > On 28/03/17 16:27, Boris Ostrovsky wrote: > > On 03/28/2017 04:08 AM, Jan Beulich wrote: > > On 28.03.17 at 03:57, wrote: > >>> I think there is indeed a disconnect between target memory (provided by > >>> the toolstack) and current memory (i.e actual pages available to the > >>> guest). > >>> > >>> For example > >>> > >>> [0.00] BIOS-e820: [mem 0x0009e000-0x0009] > >>> reserved > >>> [0.00] BIOS-e820: [mem 0x000e-0x000f] > >>> reserved > >>> > >>> are missed in target calculation. The hvmloader marks them as RESERVED > >>> (in build_e820_table()) but target value is not aware of this action. > >>> > >>> And then the same problem repeats when kernel removes > >>> 0x000a-0x000f chunk. > >> But this is all in-guest behavior, i.e. nothing an entity outside the > >> guest (tool stack or hypervisor) should need to be aware of. That > >> said, there is still room for improvement in the tools I think: > >> Regions which architecturally aren't RAM (namely the > >> 0xa-0xf range) would probably better not be accounted > >> for as RAM as far as ballooning is concerned. In the hypervisor, > >> otoh, all memory assigned to the guest (i.e. including such backing > >> ROMs) needs to be accounted. > > > > On the Linux side we should not include in balloon calculations pages > > reserved by trim_bios_range(), i.e. (BIOS_END-BIOS_BEGIN) + 1. > > > > Which leaves hvmloader's special pages (and possibly memory under > > 0xA which may get reserved). Can we pass this info to guests via > > xenstore? > > I'd rather keep an internal difference between online pages and E820-map > count value in the balloon driver. This should work always. Did we ever come with a patch for this?
[PATCH] input: mouse: bcm5974: Add driver for Apple Magic Trackpad 2
From: Marek Wyborski
Added support for Apple Magic Trackpad 2 in bcm5974 (MacBook Tochpad) driver.
The Magic Trackpad 2 needs to be switched into the finger-reporting-mode,
just like the other macbook touchpads as well. But the format is different to
the ones before. The Header is 12 Bytes long and each reported finger is
additional 9 Bytes. The data order is as well different.
The driver currently only supports USB. One option would be to integrate
bluetooth support into the bcm driver or to move the driver to the
hid-magicmouse which supports bluetooth. I integrated the driver into the bcm
and not the magicmouse driver, because this way i was able to compare the
outcome with the macbook touchpad as i dont own a magicmouse or a magictrackpad.
The patch has been tested by several people with a dkms:
https://github.com/robbi5/magictrackpad2-dkms
https://github.com/torvalds/linux/pull/332
Signed-off-by: Marek Wyborski
---
drivers/hid/hid-apple.c | 2 +
drivers/hid/hid-core.c| 2 +
drivers/hid/hid-ids.h | 1 +
drivers/input/mouse/bcm5974.c | 123 ++
4 files changed, 117 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 2e046082210f..c28af08d23ee 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -554,6 +554,8 @@ static const struct hid_device_id apple_devices[] = {
.driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING9_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICTRACKPAD2),
+ .driver_data = APPLE_HAS_FN },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 2241e7913c0d..c57cec669ac8 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1869,6 +1869,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING9_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING9_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING9_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS) },
@@ -2746,6 +2747,7 @@ static const struct hid_device_id hid_mouse_ignore_list[]
= {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING9_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING9_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_WELLSPRING9_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY) },
{ }
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4f9a3938189a..6b3e7ee177f2 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -86,6 +86,7 @@
#define USB_DEVICE_ID_APPLE_MIGHTYMOUSE0x0304
#define USB_DEVICE_ID_APPLE_MAGICMOUSE 0x030d
#define USB_DEVICE_ID_APPLE_MAGICTRACKPAD 0x030e
+#define USB_DEVICE_ID_APPLE_MAGICTRACKPAD2 0x0265
#define USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI 0x020e
#define USB_DEVICE_ID_APPLE_FOUNTAIN_ISO 0x020f
#define USB_DEVICE_ID_APPLE_GEYSER_ANSI0x0214
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index d0122134f320..2fe645c068cd 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -16,6 +16,7 @@
* Copyright (C) 2005 Peter Osterlund (pete...@telia.com)
* Copyright (C) 2005 Michael Hanselmann (linux-ker...@hansmi.ch)
* Copyright (C) 2006 Nicolas Boichat (nico...@boichat.ch)
+ * Copyright (C) 2016 Marek Wyborski (marek.wybor...@emwesoft.com)
*
* 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
@@ -96,6 +97,8 @@
#define USB_DEVICE_ID_APPLE_WELLSPRING9_ANSI 0x0272
#define USB_DEVICE_ID_APPLE_WELLSPRING9_ISO0x0273
#define USB_DEVICE_ID_APPLE_WELLSPRING9_JIS0x0274
+/* MagicTrackpad2 (2015) */
+#define USB_DEVICE_ID_APPLE_MAGICTRACKPAD2 0x026
Re: [PATCH 1/2] staging: media: atomisp2: css2400: Replace kfree()/vfree() with kvfree()
On Fri, 2017-07-07 at 20:40 -0400, Amitoj Kaur Chawla wrote:
> Conditionally calling kfree()/vfree() can be replaced by a call to
> kvfree() which handles both kmalloced memory and vmalloced memory.
[]
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
[]
> @@ -2029,10 +2029,7 @@ void *sh_css_calloc(size_t N, size_t size)
>
> void sh_css_free(void *ptr)
> {
> - if (is_vmalloc_addr(ptr))
> - vfree(ptr);
> - else
> - kfree(ptr);
> + kvfree(ptr);
> }
Why not just get rid of sh_css_free and use kvfree directly?
Why not get rid of all the sh_css_ functions?
[PATCH] auxdisplay: ht16k33: constify fb_fix_screeninfo and fb_var_screeninfo structures
These structures are only used to copy into other structures,
so declare them as const.
This issue was detected using Coccinelle and the following semantic patch:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct fb_fix_screeninfo i@p = { ... };
@ok@
identifier r.i;
expression e;
position p;
@@
e = i@p
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct fb_fix_screeninfo e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct fb_fix_screeninfo i = { ... };
The semantic patch for fb_var_screeninfo is analogous.
Signed-off-by: Gustavo A. R. Silva
---
drivers/auxdisplay/ht16k33.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index fbfa5b4..a0162b5 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -82,7 +82,7 @@ struct ht16k33_priv {
struct ht16k33_fbdev fbdev;
};
-static struct fb_fix_screeninfo ht16k33_fb_fix = {
+static const struct fb_fix_screeninfo ht16k33_fb_fix = {
.id = DRIVER_NAME,
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_MONO10,
@@ -93,7 +93,7 @@ static struct fb_fix_screeninfo ht16k33_fb_fix = {
.accel = FB_ACCEL_NONE,
};
-static struct fb_var_screeninfo ht16k33_fb_var = {
+static const struct fb_var_screeninfo ht16k33_fb_var = {
.xres = HT16K33_MATRIX_LED_MAX_ROWS,
.yres = HT16K33_MATRIX_LED_MAX_COLS,
.xres_virtual = HT16K33_MATRIX_LED_MAX_ROWS,
--
2.5.0
Re: [iovisor-dev] [PATCH v3 net-next 02/12] bpf/verifier: rework value tracking
Nadav Amit wrote:
> Edward Cree wrote:
>
>> On 06/07/17 22:21, Nadav Amit wrote:
>>> I find it a bit surprising that such huge changes that can affect security
>>> and robustness are performed in one patch.
>> In the first version of the series, this was two patches, with "feed
>> pointer-to-unknown-scalar casts into scalar ALU path" split out from the
>> rest;
>> but that just caused a lot of code movement and confusing diffs, hence why I
>> folded it into the same patch.
>> As for the rest of it, I'm not sure it can be split up: I'm changing the
>> definition and semantics of a core data structure (struct bpf_reg_state)
>> and I don't see any reasonable intermediate steps that would even compile.
>> For instance, replacing reg->imm (with its two meanings of 'known value' or
>> 'number of leading zero bits') with reg->var_off necessitates replacing all
>> the arithmetic-handling code (e.g. evaluate_reg_imm_alu()). But then
>> var_off also replaces reg->aux_align[_off], so all the alignment-checking
>> code has to change as well. And changing what register state we track
>> means that the pruning code (states_equal()) has to change too.
>> As it is, this patch leaves some selftests failing and it takes _another_
>> big patch (4/12 "track signed and unsigned min/max values") to get them
>> all to pass again.
>
> Thanks for your polite response to my rantings. I do understand the
> complexity, and I did not like the two meanings of reg->imm either (it took
> me some time to understand them). Yet, I really doubt anyone is capable of
> really reviewing such a big patch. Most likely people will not even start or
> pick to small details they know or care about.
>
>>> Personally, I cannot comprehend
>>> all of these changes. In addition, I think that it is valuable to describe
>>> in detail the bugs that the patch solves and when they were introduced.
>> Mostly this patch series isn't about fixing bugs (except those which were
>> exposed when the changes caused some selftests to fail). Instead, it's a
>> combination of refactoring and unifying so that (for instance) the rules
>> for pointer arithmetic and alignment checking are as similar as possible
>> for all pointer types rather than having special-case rules for each type.
>> This allows many (correct) programs which the verifier will currently
>> reject, and makes the overall description of the verifier's rules much
>> shorter and simpler. I have written a documentation patch explaining
>> these rules, which the next version of the patch series will include.
>
> Ok. But I doubt it is as useful as commenting in the code or writing in the
> commit message what exactly is addressed by the patch. And documentation
> does not really help others to rebase their patches on top of yours.
>
>> The diff _is_ hard to read, I accept that; I think `diff` was too eager to
>> interpolate and match single lines like '{' from completely unrelated
>> functions. It might be easier to just try applying the patch to a tree
>> and then reading the result, rather than trying to interpret the diff.
>
> I don’t know to review patches this way. Hopefully others do, but I doubt it.
>
> For me changes such as:
>
>> if (dst_reg->min_value != BPF_REGISTER_MIN_RANGE)
>> -dst_reg->min_value -= min_val;
>> +dst_reg->min_value -= max_val;
>
>
> are purely cryptic. What happened here? Was there a bug before and if so
> what are its implications? Why can’t it be in a separate patch?
>
> I also think that changes such as:
>> -s64 min_value;
>> -u64 max_value;
> [snip]
>> +s64 min_value; /* minimum possible (s64)value */
>> +u64 max_value; /* maximum possible (u64)value */
>
> Should have been avoided. Personally, I find this comment redundant (to say
> the least). It does not help to reduce the diff size.
>
> In this regard, I think that refactoring should have been done first and not
> together with the logic changes. As another example, changing UNKNOWN_VALUE
> to SCALAR_VALUE should have been a separate, easy to understand patch.
>
>>> I can bring up some concerns regarding inconsistencies in offset checks and
>>> size, not spilling SCALAR and my wish not to limit packet size. However,
>>> when the patch is that big, I think it is useless.
>> Please, do describe these concerns; what inconsistencies do you see?
>> The not spilling scalars, and the limit to packet size, are retained
>> from the existing code (is_spillable_regtype() and MAX_PACKET_OFF).
>> The latter is also needed for correctness in computing reg->range;
>> if 'pkt_ptr + offset' could conceivably overflow, then the result
>> could be < pkt_end without being a valid pointer into the packet.
>> We thus rely on the assumption that the packet pointer will never be
>> within MAX_PACKET_OFF of the top of the address space. (This
>> assumption is, again, carried over from the existing verifier.)
>
> I understand the limitations (I think). I agree that CO
Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
On Fri, Jul 7, 2017 at 5:30 PM, Casey Leedom wrote: > By the way, it ~seems~ like the patch set confuses the idea of the PCIe > Capability Device Control[Relaxed Ordering Enable] with the device's ability > to handle incoming TLPs with the Relaxed Ordering Attribute set. These are > completely different things. The PCIe Capability Device Control[Relaxed > Ordering Enable] solely governs the ability of the device to _send_ TLPs with > the Relaxed Ordering Attribute set. It has nothing whatsoever to do with the > handling of incoming TLPs with the Relaxed Ordering Attribute set. In fact, > there is any standard way to disable receipt processing of such TLPs. That's > kind of the whole point of the majority of the patch. If there was a > separate "Ignore Incoming Relaxed Ordering Attributes" then we'd mostly just > have a quirk which would set that for problematic devices. > > Worse yet, if I'm reading the patch right, it _is_ turning off the PCIe > Capability Device Control[Relaxed Ordering Enable] for the devices that we've > identified with problematic receive handling. Not only does this not solve > the problem that we've been talking about, it actually almost certainly > introduces a huge Graphics Performance Bug. The Relaxed Ordering Attribute > was originally developed for Graphics Device support in order to download > textures, etc. to a graphics devices as fast as possible and only ensure > ordering at points where needed. For instance, as far as I know, the Intel > Root Complexes that we've been talking about have no issues whatsoever in > generating downstream TLPs with the Relaxed Ordering Attribute set. By > turning off the PCIe Capability Device Control[Relaxed Ordering Enable] on > these Root Complexes, this patch prevents the generation of downstream TLPs > with the Relaxed Ordering Attribute set targeted at devices like graphics > adapters. > > Casey The patches should be disabling the relaxed ordering on upstream facing ports that would be sending requests to the root complex. So if the root complex cannot handle receiving a message with relaxed ordering enabled we should be clearing the relaxed ordering bit in the PCIe configuration on those device that could send TLPs to that root complex. By doing that the devices hosted on that root complex cannot generate requests that contain relaxed ordering TLPs. I'll have to do some double checking of the patches, but I thought we were only clearing the relaxed ordering bits on the devices that would be sending requests to the root complex, not the downstream ports of the root complex itself. As such we should be able to generate relaxed ordering TLPs from the root complex, but the devices hosted on the bus shouldn't be able to generate relaxed ordering TLPs. The bit in the configuration space controls the ability to generate content, not the ability to receive it so clearing the bit on the device should be the correct behavior for this. As far as your suggestions for the cxgb4 patch it has the same problem it originally had. We want to disable the relaxed ordering bit on the device since the device should not be generating relaxed ordering requests. This is why I was trying to get your input on this as I know you have a peer-to-peer configuration that you wanted to support. What we need to do is identify what platforms cannot support relaxed ordering to the root complex and prevent that from happening which is why we clear the relaxed ordering bit on the device. In that setup we need to have a good way to identify when this has occurred and instead setup a side channel type configuration where we then re-enable relaxed ordering, but only allow for sending directly to the peer and not the root complex. - Alex
[PATCH] watchdog: it87_wdt: constify watchdog_ops structure
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
---
drivers/watchdog/it87_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index dd1e7ea..e96faea 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -253,7 +253,7 @@ static const struct watchdog_info ident = {
.identity = WATCHDOG_NAME,
};
-static struct watchdog_ops wdt_ops = {
+static const struct watchdog_ops wdt_ops = {
.owner = THIS_MODULE,
.start = wdt_start,
.stop = wdt_stop,
--
2.5.0
[PATCH 2/2] staging: media: atomisp2: Replace kfree()/vfree() with kvfree()
Conditionally calling kfree()/vfree() can be replaced by a call to
kvfree() which handles both kmalloced memory and vmalloced memory.
Consequently removed an unnecessary comment.
The Coccinelle semantic patch used to make the change is as follows:
//
@@
expression a;
@@
- if(...) { vfree(a); }
- else { kfree(a); }
+ kvfree(a);
@@
expression a;
@@
- if(...) { kfree(a); }
- else { vfree(a); }
+ kvfree(a);
//
Signed-off-by: Amitoj Kaur Chawla
---
drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 97093ba..a156dd424 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -117,11 +117,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool zero_mem)
*/
void atomisp_kernel_free(void *ptr)
{
- /* Verify if buffer was allocated by vmalloc() or kmalloc() */
- if (is_vmalloc_addr(ptr))
- vfree(ptr);
- else
- kfree(ptr);
+ kvfree(ptr);
}
/*
--
2.7.4
[PATCH 1/2] staging: media: atomisp2: css2400: Replace kfree()/vfree() with kvfree()
Conditionally calling kfree()/vfree() can be replaced by a call to
kvfree() which handles both kmalloced memory and vmalloced memory.
The Coccinelle semantic patch used to make the change is as follows:
//
@@
expression a;
@@
- if(...) { vfree(a); }
- else { kfree(a); }
+ kvfree(a);
@@
expression a;
@@
- if(...) { kfree(a); }
- else { vfree(a); }
+ kvfree(a);
//
Signed-off-by: Amitoj Kaur Chawla
---
drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
index 73c7658..1b0708f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
@@ -2029,10 +2029,7 @@ void *sh_css_calloc(size_t N, size_t size)
void sh_css_free(void *ptr)
{
- if (is_vmalloc_addr(ptr))
- vfree(ptr);
- else
- kfree(ptr);
+ kvfree(ptr);
}
/* For Acceleration API: Flush FW (shared buffer pointer) arguments */
--
2.7.4
Re: [git pull] drm fixes for 4.12-rc8
On Wed, Jun 28, 2017 at 12:18 AM, Dave Airlie wrote: > > I've got next locked down, so whenever you open the merge > window and I get back I'll send it to you. Just checking in on this part.. I think the drm stuff it the major missing piece for 4.13 now. Linus
[PATCH] watchdog: coh901327_wdt: constify watchdog_ops structure
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
---
drivers/watchdog/coh901327_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/coh901327_wdt.c b/drivers/watchdog/coh901327_wdt.c
index 38dd60f0..4410337 100644
--- a/drivers/watchdog/coh901327_wdt.c
+++ b/drivers/watchdog/coh901327_wdt.c
@@ -218,7 +218,7 @@ static const struct watchdog_info coh901327_ident = {
.identity = DRV_NAME,
};
-static struct watchdog_ops coh901327_ops = {
+static const struct watchdog_ops coh901327_ops = {
.owner = THIS_MODULE,
.start = coh901327_start,
.stop = coh901327_stop,
--
2.5.0
[PATCH 1/3] of: overlay: add overlay unittest data for node names and symbols
From: Frank Rowand Add nodes and properties to overlay_base and overlay dts files to test for - incorrect existing node name detection when overlay node name has a unit-address - adding overlay __symbols__ properties to live tree when an overlay is added to the live tree Expected result from patch 2/3 is overlay will update the nodes and properties for /testcase-data-2/fairway-1/ride@100/ Before patch 2/3 is applied: Console error message near end of unittest: OF: Duplicate name in fairway-1, renamed to "ride@100#1" $ cd /proc/device-tree/testcase-data-2/fairway-1/ $ # extra node: ride@100#1 $ ls #address-cells linux,phandle phandle ride@200 #size-cells nameride@100status compatible orientation ride@100#1 $ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/ $ ls track@3/incline_up ls: track@3/incline_up: No such file or directory $ ls track@4/incline_up ls: track@4/incline_up: No such file or directory After patch 2/3 is applied: Console error message no longer occurs $ cd /proc/device-tree/testcase-data-2/fairway-1/ $ # no extra node: ride@100#1 $ ls #address-cells compatible namephandle ride@200 #size-cells linux,phandle orientation ride@100status $ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/ $ ls track@3/incline_up track@3/incline_up $ ls track@4/incline_up track@4/incline_up Expected result from patch 3/3 is new __symbols__ entries for labels from the overlay _after_ the add overlay symbols patch is also applied. Before patch 3/3 is applied: Console error message near end of unittest: ### dt-test ### FAIL of_unittest_overlay_high_level():2296 Adding overlay 'overlay_bad_symbol' failed ### dt-test ### end of unittest - 190 passed, 1 failed The new unittest "fails" because the expected result of loading the new overlay is an error instead of success. $ # node hvac-medium-2 exists because the overlay loaded $ # since the duplicate symbol was not detected $ cd /proc/device-tree/testcase-data-2/substation@100/ $ ls compatible hvac-medium-2 motor-8reg hvac-large-1 linux,phandle name status hvac-medium-1 motor-1phandle $ cd /proc/device-tree/__symbols__/ $ ls electric_1 lights_1 name rides_1 spin_ctrl_2 hvac_1 lights_2 retail_1 spin_ctrl_1 After patch 3/3 is applied: Previous console error message no longer occurs, but expected error occurs: OF: overlay: Failed to apply prop @/__symbols__/hvac_1 OF: overlay: apply failed '/__symbols__' ### dt-test ### end of unittest - 191 passed, 0 failed $ # node hvac-medium-2 does not exist because the overlay $ # properly failed to load due to the duplicate symbol $ cd /proc/device-tree/testcase-data-2/substation@100/ $ ls compatible hvac-medium-1 motor-1name reg hvac-large-1 linux,phandle motor-8phandlestatus $ cd /proc/device-tree/__symbols__/ $ ls electric_1 lights_1retail_1ride_200_right spin_ctrl_2 hvac_1 lights_2ride_200rides_1 hvac_2 nameride_200_left spin_ctrl_1 $ cat ride_200; echo /testcase-data-2/fairway-1/ride@200 $ cat ride_200_left ; echo /testcase-data-2/fairway-1/ride@200/track@1 $ cat ride_200_right ; echo /testcase-data-2/fairway-1/ride@200/track@2 Signed-off-by: Frank Rowand --- drivers/of/unittest-data/Makefile | 3 +++ drivers/of/unittest-data/overlay.dts| 19 ++- drivers/of/unittest-data/overlay_bad_symbol.dts | 22 ++ drivers/of/unittest-data/overlay_base.dts | 7 +++ drivers/of/unittest.c | 6 ++ 5 files changed, 56 insertions(+), 1 deletion(-) create mode 100644 drivers/of/unittest-data/overlay_bad_symbol.dts diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile index 6e00a9c69e58..dae2fe23cd2e 100644 --- a/drivers/of/unittest-data/Makefile +++ b/drivers/of/unittest-data/Makefile @@ -1,11 +1,13 @@ obj-y += testcases.dtb.o obj-y += overlay.dtb.o obj-y += overlay_bad_phandle.dtb.o +obj-y += overlay_bad_symbol.dtb.o obj-y += overlay_base.dtb.o targets += testcases.dtb testcases.dtb.S targets += overlay.dtb overlay.dtb.S targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S +targets += overlay_bad_symbol.dtb overlay_bad_symbol.dtb.S targets += overlay_base.dtb overlay_base.dtb.S .PRECIOUS: \ @@ -15,4 +17,5 @@ targets += overlay_base.dtb overlay_base.dtb.S # enable creation of __symbols__ node DTC_FLAGS_overlay := -@ DTC_FLAGS_overlay_bad_phandle := -@ +DTC_FLAGS_overlay_bad_symbol := -@ DTC_FLAGS_overlay_base := -@ diff --git a/drivers/of/unittest-data/overlay.dts b/driver
[git pull] vfs.git pile 15 - more non-uaccess bits
Assorted normal VFS / filesystems stuff... [this is not all; there are several branches left, but that's for tomorrow] The following changes since commit 41f1830f5a7af77cf5c86359aba3cbd706687e52: Linux 4.12-rc6 (2017-06-19 22:19:37 +0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for you to fetch changes up to 49d31c2f389acfe83417083e1208422b4091cd9e: dentry name snapshots (2017-07-07 20:09:10 -0400) Al Viro (1): dentry name snapshots Carlos Maiolino (1): Make statfs properly return read-only state after emergency remount Denys Vlasenko (1): minix: Deinline get_block, save 2691 bytes Kees Cook (1): fs: Reorder inode_owner_or_capable() to avoid needless Luis R. Rodriguez (1): fs: warn in case userspace lied about modprobe return Sebastian Andrzej Siewior (1): fs/dcache: init in_lookup_hashtable fs/dcache.c | 32 fs/debugfs/inode.c | 10 +- fs/filesystems.c | 4 +++- fs/inode.c | 2 +- fs/minix/itree_common.c | 2 +- fs/namei.c | 10 +- fs/notify/fsnotify.c | 8 ++-- fs/statfs.c | 2 ++ include/linux/dcache.h | 6 ++ include/linux/fsnotify.h | 31 --- 10 files changed, 61 insertions(+), 46 deletions(-)
[git pull] vfs.git pile 14 - spi uaccess delousing
Getting rid of pointless __get_user() and friends in drivers/spi [the only reason it's on a separate branch is that I hoped it would be picked by spi folks; looks like mail asking them to grab it got lost and I hadn't followed up on that] The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-spi for you to fetch changes up to 251d59515fe4681a64a8bc7e37cfa00701e0f9b0: spidev: quit messing with access_ok() (2017-06-29 18:00:52 -0400) Al Viro (1): spidev: quit messing with access_ok() drivers/spi/spidev.c | 42 +++--- 1 file changed, 11 insertions(+), 31 deletions(-)
[git pull] vfs.git pile 13 - killing __copy_in_user()
There used to be 6 places in the entire tree calling __copy_in_user(), all of them bogus. Four got killed off in work.drm branch, this takes care of the remaining ones and kills the definition of that sucker. The following changes since commit aeba03903063e9fea885d32318e1546d9b7e83a8: mga: switch compat ioctls to drm_ioctl_kernel() (2017-07-04 13:16:28 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.__copy_in_user for you to fetch changes up to 119d0312c766773ca3238b9d926077664eed22be: kill __copy_in_user() (2017-07-04 13:31:27 -0400) Al Viro (3): sanitize do_i2c_smbus_ioctl() Merge branch 'work.drm' into work.__copy_in_user kill __copy_in_user() fs/compat_ioctl.c | 19 +-- include/linux/uaccess.h | 6 -- 2 files changed, 9 insertions(+), 16 deletions(-)
Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
By the way, it ~seems~ like the patch set confuses the idea of the PCIe Capability Device Control[Relaxed Ordering Enable] with the device's ability to handle incoming TLPs with the Relaxed Ordering Attribute set. These are completely different things. The PCIe Capability Device Control[Relaxed Ordering Enable] solely governs the ability of the device to _send_ TLPs with the Relaxed Ordering Attribute set. It has nothing whatsoever to do with the handling of incoming TLPs with the Relaxed Ordering Attribute set. In fact, there is any standard way to disable receipt processing of such TLPs. That's kind of the whole point of the majority of the patch. If there was a separate "Ignore Incoming Relaxed Ordering Attributes" then we'd mostly just have a quirk which would set that for problematic devices. Worse yet, if I'm reading the patch right, it _is_ turning off the PCIe Capability Device Control[Relaxed Ordering Enable] for the devices that we've identified with problematic receive handling. Not only does this not solve the problem that we've been talking about, it actually almost certainly introduces a huge Graphics Performance Bug. The Relaxed Ordering Attribute was originally developed for Graphics Device support in order to download textures, etc. to a graphics devices as fast as possible and only ensure ordering at points where needed. For instance, as far as I know, the Intel Root Complexes that we've been talking about have no issues whatsoever in generating downstream TLPs with the Relaxed Ordering Attribute set. By turning off the PCIe Capability Device Control[Relaxed Ordering Enable] on these Root Complexes, this patch prevents the generation of downstream TLPs with the Relaxed Ordering Attribute set targeted at devices like graphics adapters. Casey
[git pull] vfs.git pile 12 - work.read_write bugfix
file_start_write()/file_end_write() got mixed into vfs_iter_write() by
accident; that's a deadlock for all existing callers - they already
do that, some - quite a bit outside. Easily fixed, fortunately
The following changes since commit a4058c5bce8aded1a12a59990e84e481a96fb490:
nfsd: remove nfsd_vfs_read (2017-06-29 17:49:24 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.read_write
for you to fetch changes up to 62473a2d6f513296e896b64ccfd7ceb7b963795e:
move file_{start,end}_write() out of do_iter_write() (2017-07-06 09:15:47
-0400)
Al Viro (1):
move file_{start,end}_write() out of do_iter_write()
fs/read_write.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
[git pull] vfs.git pile 11 - iov_iter/hardening
iov_iter/uaccess/hardening pile. For one thing, it trims the
inline part of copy_to_user/copy_from_user to the minimum that *does*
need to be inlined - object size checks, basically. For another,
it sanitizes the checks for iov_iter primitives. There are 4 groups
of checks: access_ok(), might_fault(), object size and KASAN.
* access_ok() had been verified by whoever had set the iov_iter
up. However, that has happened in a function far away, so proving that
there's no path to actual copying bypassing those checks is hard and
proving that iov_iter has not been buggered in the meanwhile is also
not pleasant. So we want those redone in actual copyin/copyout.
* might_fault() is better off consolidated - we know whether
it needs to be checked as soon as we enter iov_iter primitive and
observe the iov_iter flavour. No need to wait until the copyin/copyout.
The call chains are short enough to make sure we won't miss anything -
in fact, it's more robust that way, since there are cases where we do
e.g. forced fault-in before getting to copyin/copyout. It's not quite
what we need to check (in particular, combination of iovec-backed
and set_fs(KERNEL_DS) is almost certainly a bug, not a cause to skip
checks), but that's for later series. For now let's keep might_fault().
* KASAN checks belong in copyin/copyout - at the same level
where other iov_iter flavours would've hit them in memcpy().
* object size checks should apply to *all* iov_iter flavours,
not just iovec-backed ones.
There are two groups of primitives - one gets the kernel object
described as pointer + size (copy_to_iter(), etc.) while another gets
it as page + offset + size (copy_page_to_iter(), etc.)
For the first group the checks are best done where we actually
have a chance to find the object size. In other words, those belong in
inline wrappers in uio.h, before calling into iov_iter.c. Same kind
as we have for inlined part of copy_to_user().
For the second group there is no object to look at - offset in
page is just a number, it bears no type information. So we do them
in the common helper called by iov_iter.c primitives of that kind.
All it currently does is checking that we are not trying to access
outside of the compound page; eventually we might want to add some
sanity checks on the page involved.
So the things we need in copyin/copyout part of iov_iter.c
do not quite match anything in uaccess.h (we want no zeroing, we *do*
want access_ok() and KASAN and we want no might_fault() or object size
checks done on that level). OTOH, these needs are simple enough to
provide a couple of helpers (static in iov_iter.c) doing just what
we need...
Trivial conflicts with libnvdimm; this stuff will get some
followups, but again, that's for another series.
The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
uaccess-work.iov_iter
for you to fetch changes up to 09fc68dc66f7597bdc8898c991609a48f061bed5:
iov_iter: saner checks on copyin/copyout (2017-07-07 05:18:09 -0400)
Al Viro (5):
copy_{from,to}_user(): move kasan checks and might_fault() out-of-line
copy_{to,from}_user(): consolidate object size checks
iov_iter/hardening: move object size checks to inlined part
iov_iter: sanity checks for copy to/from page primitives
iov_iter: saner checks on copyin/copyout
include/linux/thread_info.h | 27 +
include/linux/uaccess.h | 44 +
include/linux/uio.h | 58 +---
lib/iov_iter.c | 94 -
lib/usercopy.c | 10 -
5 files changed, 165 insertions(+), 68 deletions(-)
[PATCH] watchdog: stm32_iwdg: constify watchdog_ops structure
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
---
drivers/watchdog/stm32_iwdg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index 6c501b7..be64a86 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -140,7 +140,7 @@ static const struct watchdog_info stm32_iwdg_info = {
.identity = "STM32 Independent Watchdog",
};
-static struct watchdog_ops stm32_iwdg_ops = {
+static const struct watchdog_ops stm32_iwdg_ops = {
.owner = THIS_MODULE,
.start = stm32_iwdg_start,
.ping = stm32_iwdg_ping,
--
2.5.0
[PATCH 2/3] of: overlay: correctly apply overlay node with unit-address
From: Frank Rowand
Correct existing node name detection when overlay node name has
a unit-address.
Expected test result is overlay will update the nodes and properties
for /testcase-data-2/fairway-1/ride@100/ after the patch is applied.
Before this patch is applied:
Console error message near end of unittest:
OF: Duplicate name in fairway-1, renamed to "ride@100#1"
$ cd /proc/device-tree/testcase-data-2/fairway-1/
$ # extra node: ride@100#1
$ ls
#address-cells linux,phandle phandle ride@200
#size-cells nameride@100status
compatible orientation ride@100#1
$ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/
$ ls track@3/incline_up
ls: track@3/incline_up: No such file or directory
$ ls track@4/incline_up
ls: track@4/incline_up: No such file or directory
After this patch is applied:
Console error message no longer occurs
$ cd /proc/device-tree/testcase-data-2/fairway-1/
$ # no extra node: ride@100#1
$ ls
#address-cells compatible namephandle ride@200
#size-cells linux,phandle orientation ride@100status
$ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/
$ ls track@3/incline_up
track@3/incline_up
$ ls track@4/incline_up
track@4/incline_up
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index c0e4ee1cd1ba..30aef515 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -118,6 +118,24 @@ static int of_overlay_apply_single_property(struct
of_overlay *ov,
return of_changeset_update_property(&ov->cset, target, propn);
}
+static struct device_node *child_by_full_name(const struct device_node *np,
+ const char *cname)
+{
+ struct device_node *child;
+ struct device_node *prev;
+
+ child = np->child;
+ while (child) {
+ of_node_get(child);
+ if (!of_node_cmp(cname, kbasename(child->full_name)))
+ break;
+ prev = child;
+ child = child->sibling;
+ of_node_put(prev);
+ }
+ return child;
+}
+
static int of_overlay_apply_single_device_node(struct of_overlay *ov,
struct device_node *target, struct device_node *child)
{
@@ -130,7 +148,7 @@ static int of_overlay_apply_single_device_node(struct
of_overlay *ov,
return -ENOMEM;
/* NOTE: Multiple mods of created nodes not supported */
- tchild = of_get_child_by_name(target, cname);
+ tchild = child_by_full_name(target, cname);
if (tchild != NULL) {
/* new overlay phandle value conflicts with existing value */
if (child->phandle)
--
Frank Rowand
[PATCH 3/3] of: overlay: add overlay symbols to live device tree
From: Frank Rowand
Add overlay __symbols__ properties to live tree when an overlay
is added to the live tree so that the symbols are available to
subsequent overlays.
Expected test result is new __symbols__ entries for labels from
the overlay after the patch is applied.
Before this patch is applied:
Console error message near end of unittest:
### dt-test ### FAIL of_unittest_overlay_high_level():2296 Adding overlay
'overlay_bad_symbol' failed
### dt-test ### end of unittest - 190 passed, 1 failed
The new unittest "fails" because the expected result of loading the
new overlay is an error instead of success.
$ # node hvac-medium-2 exists because the overlay loaded
$ # since the duplicate symbol was not detected
$ cd /proc/device-tree/testcase-data-2/substation@100/
$ ls
compatible hvac-medium-2 motor-8reg
hvac-large-1 linux,phandle name status
hvac-medium-1 motor-1phandle
$ cd /proc/device-tree/__symbols__/
$ ls
electric_1 lights_1 name rides_1 spin_ctrl_2
hvac_1 lights_2 retail_1 spin_ctrl_1
After this patch is applied:
Previous console error message no longer occurs, but expected error
occurs:
OF: overlay: Failed to apply prop @/__symbols__/hvac_1
OF: overlay: apply failed '/__symbols__'
### dt-test ### end of unittest - 191 passed, 0 failed
$ # node hvac-medium-2 does not exist because the overlay
$ # properly failed to load due to the duplicate symbol
$ cd /proc/device-tree/testcase-data-2/substation@100/
$ ls
compatible hvac-medium-1 motor-1name reg
hvac-large-1 linux,phandle motor-8phandlestatus
$ cd /proc/device-tree/__symbols__/
$ ls
electric_1 lights_1retail_1ride_200_right spin_ctrl_2
hvac_1 lights_2ride_200rides_1
hvac_2 nameride_200_left spin_ctrl_1
$ cat ride_200; echo
/testcase-data-2/fairway-1/ride@200
$ cat ride_200_left ; echo
/testcase-data-2/fairway-1/ride@200/track@1
$ cat ride_200_right ; echo
/testcase-data-2/fairway-1/ride@200/track@2
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 116 +++
1 file changed, 107 insertions(+), 9 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 30aef515..c484712d124a 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -35,6 +35,7 @@
struct of_overlay_info {
struct device_node *target;
struct device_node *overlay;
+ bool is_symbols_node;
};
/**
@@ -55,7 +56,8 @@ struct of_overlay {
};
static int of_overlay_apply_one(struct of_overlay *ov,
- struct device_node *target, const struct device_node *overlay);
+ struct device_node *target, const struct device_node *overlay,
+ bool is_symbols_node);
static BLOCKING_NOTIFIER_HEAD(of_overlay_chain);
@@ -92,10 +94,74 @@ static int of_overlay_notify(struct of_overlay *ov,
return 0;
}
+static struct property *dup_and_fixup_symbol_prop(struct of_overlay *ov,
+ const struct property *prop)
+{
+ struct of_overlay_info *ovinfo;
+ struct property *new;
+ const char *overlay_name;
+ char *label_path;
+ char *symbol_path;
+ const char *target_path;
+ int k;
+ int label_path_len;
+ int overlay_name_len;
+ int target_path_len;
+
+ if (!prop->value)
+ return NULL;
+ symbol_path = prop->value;
+
+ new = kzalloc(sizeof(*new), GFP_KERNEL);
+ if (!new)
+ return NULL;
+
+ for (k = 0; k < ov->count; k++) {
+ ovinfo = &ov->ovinfo_tab[k];
+ overlay_name = ovinfo->overlay->full_name;
+ overlay_name_len = strlen(overlay_name);
+ if (!strncasecmp(symbol_path, overlay_name, overlay_name_len))
+ break;
+ }
+
+ if (k >= ov->count)
+ goto err_free;
+
+ target_path = ovinfo->target->full_name;
+ target_path_len = strlen(target_path);
+
+ label_path = symbol_path + overlay_name_len;
+ label_path_len = strlen(label_path);
+
+ new->name = kstrdup(prop->name, GFP_KERNEL);
+ new->length = target_path_len + label_path_len + 1;
+ new->value = kzalloc(new->length, GFP_KERNEL);
+
+ if (!new->name || !new->value)
+ goto err_free;
+
+ strcpy(new->value, target_path);
+ strcpy(new->value + target_path_len, label_path);
+
+ /* mark the property as dynamic */
+ of_property_set_flag(new, OF_DYNAMIC);
+
+ return new;
+
+ err_free:
+ kfree(new->name);
+ kfree(new->value);
+ kfree(new);
+ return NULL;
+
+
+}
+
static int of_overlay_apply_single_property(struct of_overlay *ov,
- struct device_node *t
[PATCH 0/3] of: overlay: load overlay symbols into live device tree
From: Frank Rowand Symbols in a loaded overlay are not currently available to subsequently loaded overlays because the properties in the overlay's __symbols__ node are not loaded into the live device tree. Patch 1 is unittests to test patches 2 and 3. Patch 2 fixes a problem discovered while developing patch 3. If a node name in an overlay has a unit-address then the overlay code does not correctly match the node name against an existing node in the live tree. Patch 3 adds the properties in an overlay's __symbol__ node to the overlay changeset. This patch set was created on top of v4.12, with Rob's pull request for 4.13 added (https://lkml.org/lkml/2017/7/6/691). Thus this series should apply on 4.13-rc1 when that becomes available. I will re-test on 4.13-rc1. Frank Rowand (3): of: overlay: add overlay unittest data for node names and symbols of: overlay: correctly apply overlay node with unit-address of: overlay: add overlay symbols to live device tree drivers/of/overlay.c| 136 ++-- drivers/of/unittest-data/Makefile | 3 + drivers/of/unittest-data/overlay.dts| 19 +++- drivers/of/unittest-data/overlay_bad_symbol.dts | 22 drivers/of/unittest-data/overlay_base.dts | 7 ++ drivers/of/unittest.c | 6 ++ 6 files changed, 182 insertions(+), 11 deletions(-) create mode 100644 drivers/of/unittest-data/overlay_bad_symbol.dts -- Frank Rowand
Re: [Patch] mqueue: fix the retry logic for netlink_attachskb()
On Fri, Jul 7, 2017 at 11:32 AM, Cong Wang wrote:
> The retry logic for netlink_attachskb() inside sys_mq_notify()
> is suspicious and vulnerable:
>
> 1) The sock refcnt is already released when retry is needed
> 2) The fd is controllable by user-space because we already
>release the file refcnt
Hmm. What's different the second (and third.. and..) time around from
the first time?
I don't dislike your patch (it looks fine), but avoiding the
fdget/fdput in the retry loop doesn't seem to really change anything -
it's just as if we'd just react to the original thing a bit later.
> so we when retry and the fd has been closed during this small
> window, we end up calling netlink_detachskb() on the error path
> which releases the sock again and could lead to a use-after-free.
So this seems to be a real problem: "sock" is not NULL'ed out in that
if (!f.file) {
error case (or alternatively, in the retry case). Plus, since we did
the "fput()" early, "sock" may be gone by the time we do the
netlink_attachskb() even when it's all successful.
But I don't think this is really so much about the retrying - the
"sock may be gone" case seems to be true even the first time around,
and even if we never retry at all.
Am I reading this correctly?
Basically, I think the patch is fine, but the explanation seems a bit
misleading. This isn't really about the re-trying: that would be fine
if we just cleaned up sock properly.
Can you confirm that? I don't know where the original report is.
And that code is ancient, so we should do a "cc: stable" there too,
and backport it basically forever. I think most of the code in this
area predates the git tree, although Al Viro actually touched some
things around here very recently to make the compat case cleaner.
Linus
[PATCH] watchdog: ts72xx_wdt: constify watchdog_ops structure
Check for watchdog_ops structures that are only stored in the ops field of
a watchdog_device structure. This field is declared const, so watchdog_ops
structures that have this property can be declared as const also.
This issue was detected using Coccinelle and the following semantic patch:
@r
disable optional_qualifier@
identifier i;
position p;
@@
static struct watchdog_ops i@p = { ... };
@ok@
identifier r.i;
struct watchdog_device e;
position p;
@@
e.ops = &i@p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct watchdog_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct watchdog_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
---
drivers/watchdog/ts72xx_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/ts72xx_wdt.c b/drivers/watchdog/ts72xx_wdt.c
index 17c25da..811e43c 100644
--- a/drivers/watchdog/ts72xx_wdt.c
+++ b/drivers/watchdog/ts72xx_wdt.c
@@ -112,7 +112,7 @@ static const struct watchdog_info ts72xx_wdt_ident = {
.identity = "TS-72XX WDT",
};
-static struct watchdog_ops ts72xx_wdt_ops = {
+static const struct watchdog_ops ts72xx_wdt_ops = {
.owner = THIS_MODULE,
.start = ts72xx_wdt_start,
.stop = ts72xx_wdt_stop,
--
2.5.0
[PATCH v5 4/5] freeze: Add error reporting
This adds error reporting for cpuidle to freeze so suspend-to-idle can
report errors when the CPU/SoC is unable to idle properly. Freeze will
abort when an error is encounted.
Signed-off-by: Derek Basehore
---
drivers/acpi/processor_idle.c | 10 ++
drivers/cpuidle/cpuidle.c | 32 +++-
drivers/idle/intel_idle.c | 8 +---
include/linux/cpuidle.h | 12
kernel/power/suspend.c| 20 +---
5 files changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 5c8aa9cf62d7..1c0ac4d24563 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -789,8 +789,8 @@ static int acpi_idle_enter(struct cpuidle_device *dev,
return index;
}
-static void acpi_idle_enter_freeze(struct cpuidle_device *dev,
- struct cpuidle_driver *drv, int index)
+static int acpi_idle_enter_freeze(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
{
struct acpi_processor_cx *cx = per_cpu(acpi_cstate[index], dev->cpu);
@@ -798,16 +798,18 @@ static void acpi_idle_enter_freeze(struct cpuidle_device
*dev,
struct acpi_processor *pr = __this_cpu_read(processors);
if (unlikely(!pr))
- return;
+ return 0;
if (pr->flags.bm_check) {
acpi_idle_enter_bm(pr, cx, false);
- return;
+ return 0;
} else {
ACPI_FLUSH_CPU_CACHE();
}
}
acpi_idle_do_entry(cx);
+
+ return 0;
}
static int acpi_processor_setup_cpuidle_cx(struct acpi_processor *pr,
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 60bb64f4329d..862c55341088 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -128,9 +128,13 @@ int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
}
#ifdef CONFIG_SUSPEND
-static void enter_freeze_proper(struct cpuidle_driver *drv,
- struct cpuidle_device *dev, int index)
+static int cpuidle_freeze_error;
+
+static int enter_freeze_proper(struct cpuidle_driver *drv,
+ struct cpuidle_device *dev, int index)
{
+ int ret;
+
/*
* trace_suspend_resume() called by tick_freeze() for the last CPU
* executing it contains RCU usage regarded as invalid in the idle
@@ -143,7 +147,7 @@ static void enter_freeze_proper(struct cpuidle_driver *drv,
* suspended is generally unsafe.
*/
stop_critical_timings();
- drv->states[index].enter_freeze(dev, drv, index);
+ ret = drv->states[index].enter_freeze(dev, drv, index);
WARN_ON(!irqs_disabled());
/*
* timekeeping_resume() that will be called by tick_unfreeze() for the
@@ -152,6 +156,7 @@ static void enter_freeze_proper(struct cpuidle_driver *drv,
*/
RCU_NONIDLE(tick_unfreeze());
start_critical_timings();
+ return ret;
}
/**
@@ -164,7 +169,7 @@ static void enter_freeze_proper(struct cpuidle_driver *drv,
*/
int cpuidle_enter_freeze(struct cpuidle_driver *drv, struct cpuidle_device
*dev)
{
- int index;
+ int index, ret = 0;
/*
* Find the deepest state with ->enter_freeze present, which guarantees
@@ -173,10 +178,27 @@ int cpuidle_enter_freeze(struct cpuidle_driver *drv,
struct cpuidle_device *dev)
*/
index = find_deepest_state(drv, dev, UINT_MAX, 0, true);
if (index > 0)
- enter_freeze_proper(drv, dev, index);
+ ret = enter_freeze_proper(drv, dev, index);
+
+ if (ret < 0) {
+ cpuidle_freeze_error = ret;
+ freeze_wake();
+ }
return index;
}
+
+void cpuidle_prepare_freeze(void)
+{
+ cpuidle_freeze_error = 0;
+ cpuidle_resume();
+}
+
+int cpuidle_complete_freeze(void)
+{
+ cpuidle_pause();
+ return cpuidle_freeze_error;
+}
#endif /* CONFIG_SUSPEND */
/**
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index c2ae819a871c..ebed3f804291 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -97,8 +97,8 @@ static const struct idle_cpu *icpu;
static struct cpuidle_device __percpu *intel_idle_cpuidle_devices;
static int intel_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index);
-static void intel_idle_freeze(struct cpuidle_device *dev,
- struct cpuidle_driver *drv, int index);
+static int intel_idle_freeze(struct cpuidle_device *dev,
+struct cpuidle_driver *drv, int index);
static struct cpuidle_state *cpuidle_state_table;
/*
@@ -941,13 +941,15 @@ static __cpuidle int intel_idle(struct c
[PATCH v5 1/5] x86: stub out pmc function
This creates an inline function of intel_pmc_slp_s0_counter_read for
!CONFIG_INTEL_PMC_CORE.
Signed-off-by: Derek Basehore
---
arch/x86/include/asm/pmc_core.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/pmc_core.h b/arch/x86/include/asm/pmc_core.h
index d4855f11136d..5d142d915f30 100644
--- a/arch/x86/include/asm/pmc_core.h
+++ b/arch/x86/include/asm/pmc_core.h
@@ -22,6 +22,10 @@
#define _ASM_PMC_CORE_H
/* API to read SLP_S0_RESIDENCY counter */
-int intel_pmc_slp_s0_counter_read(u32 *data);
+#ifdef CONFIG_INTEL_PMC_CORE
+extern int intel_pmc_slp_s0_counter_read(u32 *data);
+#else
+static inline int intel_pmc_slp_s0_counter_read(u32 *data) { return -EPERM; }
+#endif
#endif /* _ASM_PMC_CORE_H */
--
2.13.2.725.g09c95d1e9-goog
[PATCH v5 2/5] tick: Add freeze timer events
Adds a new feature to tick to schedule wakeups on a CPU during freeze.
This won't fully wake up the system (devices are not resumed), but
allow simple platform functionality to be run during freeze with
little power impact.
This implementation allows an idle driver to setup a timer event with
the clock event device when entering freeze by calling
tick_set_freeze_event. Only one caller should exist for the function.
tick_freeze_event_expired is used to check if the timer went off when
the CPU wakes.
The event is cleared by tick_clear_freeze_event.
Signed-off-by: Derek Basehore
---
include/linux/clockchips.h | 9 +
include/linux/suspend.h| 2 +
kernel/time/tick-common.c | 91 ++
3 files changed, 102 insertions(+)
diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
index a116926598fd..6a3f30008020 100644
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@ -66,12 +66,20 @@ enum clock_event_state {
*/
# define CLOCK_EVT_FEAT_HRTIMER0x80
+/*
+ * Clockevent device may run during freeze
+ */
+# define CLOCK_EVT_FEAT_FREEZE_NONSTOP 0x000100
+
/**
* struct clock_event_device - clock event device descriptor
* @event_handler: Assigned by the framework to be called by the low
* level handler of the event source
* @set_next_event:set next event function using a clocksource delta
* @set_next_ktime:set next event function using a direct ktime value
+ * @event_expired: check if the programmed event is expired. Used for
+ * freeze events when timekeeping is suspended and
+ * irqs are disabled.
* @next_event:local storage for the next event in oneshot mode
* @max_delta_ns: maximum delta value in ns
* @min_delta_ns: minimum delta value in ns
@@ -100,6 +108,7 @@ struct clock_event_device {
void(*event_handler)(struct clock_event_device *);
int (*set_next_event)(unsigned long evt, struct
clock_event_device *);
int (*set_next_ktime)(ktime_t expires, struct
clock_event_device *);
+ int (*event_expired)(struct clock_event_device *);
ktime_t next_event;
u64 max_delta_ns;
u64 min_delta_ns;
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 0b1cf32edfd7..1d56269a7b31 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -248,6 +248,8 @@ static inline bool idle_should_freeze(void)
}
extern void __init pm_states_init(void);
+int tick_set_freeze_event(int cpu, ktime_t expires);
+int tick_clear_freeze_event(int cpu);
extern void freeze_set_ops(const struct platform_freeze_ops *ops);
extern void freeze_wake(void);
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 49edc1c4f3e6..688d1c0cad10 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -498,6 +498,97 @@ void tick_freeze(void)
raw_spin_unlock(&tick_freeze_lock);
}
+/**
+ * tick_set_freeze_event - Set timer to wake up the CPU from freeze.
+ *
+ * @cpu: CPU to set the clock event for
+ * @delta: time to wait before waking the CPU
+ *
+ * Returns 0 on success and -EERROR on failure.
+ */
+int tick_set_freeze_event(int cpu, ktime_t delta)
+{
+ struct clock_event_device *dev = per_cpu(tick_cpu_device, cpu).evtdev;
+ u64 delta_ns;
+ int ret;
+
+ if (!dev->set_next_event ||
+ !(dev->features & CLOCK_EVT_FEAT_FREEZE_NONSTOP)) {
+ printk_deferred(KERN_WARNING
+ "[%s] unsupported by clock event device\n",
+ __func__);
+ return -EPERM;
+ }
+
+ if (!clockevent_state_shutdown(dev)) {
+ printk_deferred(KERN_WARNING
+ "[%s] clock event device in use\n",
+ __func__);
+ return -EBUSY;
+ }
+
+ delta_ns = ktime_to_ns(delta);
+ if (delta_ns > dev->max_delta_ns || delta_ns < dev->min_delta_ns) {
+ printk_deferred(KERN_WARNING
+ "[%s] %lluns outside range: [%lluns, %lluns]\n",
+ __func__, delta_ns, dev->min_delta_ns,
+ dev->max_delta_ns);
+ return -ERANGE;
+ }
+
+ clockevents_tick_resume(dev);
+ clockevents_switch_state(dev, CLOCK_EVT_STATE_ONESHOT);
+ ret = dev->set_next_event((delta_ns * dev->mult) >> dev->shift, dev);
+ if (ret < 0) {
+ printk_deferred(KERN_WARNING
+ "Failed to program freeze event\n");
+ clockevents_shutdown(dev);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(tick_set_freeze_event);
+
+/**
+ * tick_freeze_event
[PATCH v5 3/5] x86, apic: Add freeze event support
This adds support to the clock event devices created by apic to use
freeze events. The apic is able to run a timer during freeze with near
zero power impact on modern CPUs such as skylake. This will allow
S0ix, suspend-to-idle, to be validated on Intel CPUs that support it.
This is needed because bugs with power settings on the SoC can prevent
S0ix entry. There is also no way to check this before idling all of
the CPUs.
Signed-off-by: Derek Basehore
---
arch/x86/kernel/apic/apic.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 98b3dd8cf2bf..adc69d2f11ce 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -480,6 +480,26 @@ static int lapic_next_deadline(unsigned long delta,
return 0;
}
+static int lapic_event_expired(struct clock_event_device *evt)
+{
+ u32 cct;
+
+ cct = apic_read(APIC_TMCCT);
+ return cct == 0 ? 1 : 0;
+}
+
+static int lapic_deadline_expired(struct clock_event_device *evt)
+{
+ u64 msr;
+
+ /*
+* When the timer interrupt is triggered, the register is cleared, so a
+* non-zero value indicates a pending timer event.
+*/
+ rdmsrl(MSR_IA32_TSC_DEADLINE, msr);
+ return msr == 0 ? 1 : 0;
+}
+
static int lapic_timer_shutdown(struct clock_event_device *evt)
{
unsigned int v;
@@ -534,7 +554,8 @@ static struct clock_event_device lapic_clockevent = {
.name = "lapic",
.features = CLOCK_EVT_FEAT_PERIODIC |
CLOCK_EVT_FEAT_ONESHOT |
CLOCK_EVT_FEAT_C3STOP
- | CLOCK_EVT_FEAT_DUMMY,
+ | CLOCK_EVT_FEAT_DUMMY
+ | CLOCK_EVT_FEAT_FREEZE_NONSTOP,
.shift = 32,
.set_state_shutdown = lapic_timer_shutdown,
.set_state_periodic = lapic_timer_set_periodic,
@@ -644,6 +665,7 @@ static void setup_APIC_timer(void)
levt->features &= ~(CLOCK_EVT_FEAT_PERIODIC |
CLOCK_EVT_FEAT_DUMMY);
levt->set_next_event = lapic_next_deadline;
+ levt->event_expired = lapic_deadline_expired;
clockevents_config_and_register(levt,
tsc_khz * (1000 / TSC_DIVISOR),
0xF, ~0UL);
--
2.13.2.725.g09c95d1e9-goog
[PATCH] mac80211: Fix null pointer dereference with iTXQ support
This change adds null pointer check before dereferencing pointer dev on
netif_tx_start_all_queues() when an interface is added.
With iTXQ support, netif_tx_start_all_queues() is always called while
an interface is added. however, the netdev queues are not associated
and dev is null when the interface is either NL80211_IFTYPE_P2P_DEVICE
or NL80211_IFTYPE_NAN.
Signed-off-by: Chunho Lee
---
net/mac80211/iface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index f5f5015..e2edd10 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -731,7 +731,8 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool
coming_up)
sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
local->ops->wake_tx_queue) {
/* XXX: for AP_VLAN, actually track AP queues */
- netif_tx_start_all_queues(dev);
+ if (dev)
+ netif_tx_start_all_queues(dev);
} else if (dev) {
unsigned long flags;
int n_acs = IEEE80211_NUM_ACS;
--
2.7.4
[PATCH v5 5/5] intel_idle: Add S0ix validation
This adds validation of S0ix entry and enables it on Skylake. Using
the new tick_set_freeze_event function, we program the CPU to wake up
X seconds after entering freeze. After X seconds, it will wake the CPU
to check the S0ix residency counters and make sure we entered the
lowest power state for suspend-to-idle.
It exits freeze and reports an error to userspace when the SoC does
not enter S0ix on suspend-to-idle.
One example of a bug that can prevent a Skylake CPU from entering S0ix
(suspend-to-idle) is a leaked reference count to one of the i915 power
wells. The CPU will not be able to enter Package C10 and will
therefore use about 4x as much power for the entire system. The issue
is not specific to the i915 power wells though.
Signed-off-by: Derek Basehore
---
drivers/idle/intel_idle.c | 142 +++---
1 file changed, 134 insertions(+), 8 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index ebed3f804291..d38621da6e54 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -61,10 +61,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#define INTEL_IDLE_VERSION "0.4.1"
@@ -93,12 +95,29 @@ struct idle_cpu {
bool disable_promotion_to_c1e;
};
+/*
+ * The limit for the exponential backoff for the freeze duration. At this
point,
+ * power impact is is far from measurable. It's about 3uW based on scaling from
+ * waking up 10 times a second.
+ */
+#define MAX_SLP_S0_SECONDS 1000
+#define SLP_S0_EXP_BASE 10
+
+static bool slp_s0_check;
+static unsigned int slp_s0_seconds;
+
+static DEFINE_SPINLOCK(slp_s0_check_lock);
+static unsigned int slp_s0_num_cpus;
+static bool slp_s0_check_inprogress;
+
static const struct idle_cpu *icpu;
static struct cpuidle_device __percpu *intel_idle_cpuidle_devices;
static int intel_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index);
static int intel_idle_freeze(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index);
+static int intel_idle_freeze_and_check(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index);
static struct cpuidle_state *cpuidle_state_table;
/*
@@ -597,7 +616,7 @@ static struct cpuidle_state skl_cstates[] = {
.exit_latency = 2,
.target_residency = 2,
.enter = &intel_idle,
- .enter_freeze = intel_idle_freeze, },
+ .enter_freeze = intel_idle_freeze_and_check, },
{
.name = "C1E",
.desc = "MWAIT 0x01",
@@ -605,7 +624,7 @@ static struct cpuidle_state skl_cstates[] = {
.exit_latency = 10,
.target_residency = 20,
.enter = &intel_idle,
- .enter_freeze = intel_idle_freeze, },
+ .enter_freeze = intel_idle_freeze_and_check, },
{
.name = "C3",
.desc = "MWAIT 0x10",
@@ -613,7 +632,7 @@ static struct cpuidle_state skl_cstates[] = {
.exit_latency = 70,
.target_residency = 100,
.enter = &intel_idle,
- .enter_freeze = intel_idle_freeze, },
+ .enter_freeze = intel_idle_freeze_and_check, },
{
.name = "C6",
.desc = "MWAIT 0x20",
@@ -621,7 +640,7 @@ static struct cpuidle_state skl_cstates[] = {
.exit_latency = 85,
.target_residency = 200,
.enter = &intel_idle,
- .enter_freeze = intel_idle_freeze, },
+ .enter_freeze = intel_idle_freeze_and_check, },
{
.name = "C7s",
.desc = "MWAIT 0x33",
@@ -629,7 +648,7 @@ static struct cpuidle_state skl_cstates[] = {
.exit_latency = 124,
.target_residency = 800,
.enter = &intel_idle,
- .enter_freeze = intel_idle_freeze, },
+ .enter_freeze = intel_idle_freeze_and_check, },
{
.name = "C8",
.desc = "MWAIT 0x40",
@@ -637,7 +656,7 @@ static struct cpuidle_state skl_cstates[] = {
.exit_latency = 200,
.target_residency = 800,
.enter = &intel_idle,
- .enter_freeze = intel_idle_freeze, },
+ .enter_freeze = intel_idle_freeze_and_check, },
{
.name = "C9",
.desc = "MWAIT 0x50",
@@ -645,7 +664,7 @@ static struct cpuidle_state skl_cstates[] = {
.exit_latency = 480,
.target_residency = 5000,
.enter = &intel_idle,
- .enter_freeze = intel_idle_freeze, },
+ .enter_freeze = intel_idle_freeze_and_check, },
{
.name = "C10",
.desc = "MWAIT 0x60",
@@ -653,7 +672,7 @@ static
[PATCH] drm: bridge: dw-hdmi: constify snd_pcm_ops structure
Check for snd_pcm_ops structures that are only stored in the ops field of
a snd_soc_platform_driver structure or passed as the third argument to
snd_pcm_set_ops. The corresponding field or parameter is declared const,
so snd_pcm_ops structures that have this property can be declared as
const also.
This issue was detected using Coccinelle and the following semantic patch:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_pcm_ops i@p = { ... };
@ok1@
identifier r.i;
struct snd_soc_platform_driver e;
position p;
@@
e.ops = &i@p;
@ok2@
identifier r.i;
expression e1, e2; position p;
@@
snd_pcm_set_ops(e1, e2, &i@p)
@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_pcm_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct snd_pcm_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
index 8f2d137..cf3f0ca 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
@@ -517,7 +517,7 @@ static snd_pcm_uframes_t dw_hdmi_pointer(struct
snd_pcm_substream *substream)
return bytes_to_frames(runtime, dw->buf_offset);
}
-static struct snd_pcm_ops snd_dw_hdmi_ops = {
+static const struct snd_pcm_ops snd_dw_hdmi_ops = {
.open = dw_hdmi_open,
.close = dw_hdmi_close,
.ioctl = snd_pcm_lib_ioctl,
--
2.5.0
[PATCH] libnvdimm: fix badblock range handling of ARS range
__add_badblock_range() does not account sector alignment when
it sets 'num_sectors'. Therefore, an ARS error record range
spanning across two sectors is set to a single sector length,
which leaves the 2nd sector unprotected.
Change __add_badblock_range() to set 'num_sectors' properly.
Fixes: 0caeef63e6d2f866d85bb507bf63e0ce8ec91cef
Signed-off-by: Toshi Kani
Cc: Dan Williams
Cc: Vishal Verma
Cc:
---
drivers/nvdimm/core.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 2dee908..932c3994 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -421,14 +421,15 @@ static void set_badblock(struct badblocks *bb, sector_t
s, int num)
static void __add_badblock_range(struct badblocks *bb, u64 ns_offset, u64 len)
{
const unsigned int sector_size = 512;
- sector_t start_sector;
+ sector_t start_sector, end_sector;
u64 num_sectors;
u32 rem;
start_sector = div_u64(ns_offset, sector_size);
- num_sectors = div_u64_rem(len, sector_size, &rem);
+ end_sector = div_u64_rem(ns_offset + len, sector_size, &rem);
if (rem)
- num_sectors++;
+ end_sector++;
+ num_sectors = end_sector - start_sector;
if (unlikely(num_sectors > (u64)INT_MAX)) {
u64 remaining = num_sectors;
[PATCH] usb: gadget: function: constify snd_pcm_ops structure
Check for snd_pcm_ops structures that are only stored in the ops field of
a snd_soc_platform_driver structure or passed as the third argument to
snd_pcm_set_ops. The corresponding field or parameter is declared const,
so snd_pcm_ops structures that have this property can be declared as
const also.
This issue was detected using Coccinelle and the following semantic patch:
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_pcm_ops i@p = { ... };
@ok1@
identifier r.i;
struct snd_soc_platform_driver e;
position p;
@@
e.ops = &i@p;
@ok2@
identifier r.i;
expression e1, e2; position p;
@@
snd_pcm_set_ops(e1, e2, &i@p)
@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_pcm_ops e;
@@
e@i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct snd_pcm_ops i = { ... };
Signed-off-by: Gustavo A. R. Silva
---
drivers/usb/gadget/function/u_audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_audio.c
b/drivers/usb/gadget/function/u_audio.c
index 5dd73b9..d4caa21 100644
--- a/drivers/usb/gadget/function/u_audio.c
+++ b/drivers/usb/gadget/function/u_audio.c
@@ -354,7 +354,7 @@ static int uac_pcm_null(struct snd_pcm_substream *substream)
return 0;
}
-static struct snd_pcm_ops uac_pcm_ops = {
+static const struct snd_pcm_ops uac_pcm_ops = {
.open = uac_pcm_open,
.close = uac_pcm_null,
.ioctl = snd_pcm_lib_ioctl,
--
2.5.0
Re: [PATCH v2 3/4] btrfs: Add zstd support
On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote: > On 7/6/17, 9:32 AM, "Adam Borowski" wrote: > > Got a reproducible crash on amd64: > > > > [98235.266511] BUG: unable to handle kernel paging request at > > c90001251000 > > [98235.314008] ? ZSTD_compressBlock_fast+0x94b/0xb30 > > [98235.315975] ? ZSTD_compressContinue_internal+0x1a0/0x580 > > [98235.317938] ? ZSTD_compressStream_generic+0x248/0x2f0 > > [98235.319877] ? ZSTD_compressStream+0x41/0x60 > > [98235.321821] ? zstd_compress_pages+0x236/0x5d0 > > [98235.323724] ? btrfs_compress_pages+0x5e/0x80 > > [98235.325684] ? compress_file_range.constprop.79+0x1eb/0x750 > > Thanks for the bug report Adam! I'm looking into the failure, and haven't > been able to reproduce it yet. I've built my kernel from your tree, and > I ran your script with the kernel.tar tarball 100 times, but haven't gotten > a failure yet. Crashed the same way 4 out of 4 tries for me. > I have a few questions to guide my debugging. > > - How many cores are you running with? I’ve run the script with 1, 2, and 4 > cores. > - Which version of gcc are you using to compile the kernel? I’m using > gcc-6.2.0-5ubuntu12. > - Are the failures always in exactly the same place, and does it fail 100% > of the time or just regularly? 6 cores -- all on bare metal. gcc-7.1.0-9. Lemme try with gcc-6, a different config or in a VM. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates.
Re: [PATCH] slub: make sure struct kmem_cache_node is initialized before publication
On Fri, 7 Jul 2017, Andrew Morton wrote: > On Fri, 7 Jul 2017 10:34:08 +0200 Alexander Potapenko > wrote: > > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3389,8 +3389,8 @@ static int init_kmem_cache_nodes(struct kmem_cache *s) > > return 0; > > } > > > > - s->node[node] = n; > > init_kmem_cache_node(n); > > + s->node[node] = n; > > } > > return 1; > > } > > If this matters then I have bad feelings about free_kmem_cache_nodes(): At creation time the kmem_cache structure is private and no one can run a free operation. > Inviting a use-after-free? I guess not, as there should be no way > to look up these items at this stage. Right. > Could the slab maintainers please take a look at these and also have a > think about Alexander's READ_ONCE/WRITE_ONCE question? Was I cced on these?
Re: [PATCH v2 3/4] btrfs: Add zstd support
On 7/6/17, 9:32 AM, "Adam Borowski" wrote: > On Thu, Jun 29, 2017 at 12:41:07PM -0700, Nick Terrell wrote: >> Add zstd compression and decompression support to BtrFS. zstd at its >> fastest level compresses almost as well as zlib, while offering much >> faster compression and decompression, approaching lzo speeds. > > Got a reproducible crash on amd64: > > [98235.266511] BUG: unable to handle kernel paging request at c90001251000 > [98235.267485] IP: ZSTD_storeSeq.constprop.24+0x67/0xe0 > [98235.269395] PGD 227034067 > [98235.269397] P4D 227034067 > [98235.271587] PUD 227035067 > [98235.273657] PMD 223323067 > [98235.275744] PTE 0 > > [98235.281545] Oops: 0002 [#1] SMP > [98235.283353] Modules linked in: loop veth tun fuse arc4 rtl8xxxu mac80211 > cfg80211 cp210x pl2303 rfkill usbserial nouveau video mxm_wmi ttm > [98235.285203] CPU: 0 PID: 10850 Comm: kworker/u12:9 Not tainted 4.12.0+ #1 > [98235.287070] Hardware name: System manufacturer System Product Name/M4A77T, > BIOS 240105/18/2011 > [98235.288964] Workqueue: btrfs-delalloc btrfs_delalloc_helper > [98235.290934] task: 880224984140 task.stack: c90007e5c000 > [98235.292731] RIP: 0010:ZSTD_storeSeq.constprop.24+0x67/0xe0 > [98235.294579] RSP: 0018:c90007e5fa68 EFLAGS: 00010282 > [98235.296395] RAX: c90001251001 RBX: 0094 RCX: > c9000118f930 > [98235.298380] RDX: 0006 RSI: c900011b06b0 RDI: > c9000118d1e0 > [98235.300321] RBP: 009f R08: 1fffbe58 R09: > > [98235.302282] R10: c9000118f970 R11: 0005 R12: > c9000118f878 > [98235.304221] R13: 005b R14: c9000118f915 R15: > c900011cfe88 > [98235.306147] FS: () GS:88022fc0() > knlGS: > [98235.308162] CS: 0010 DS: ES: CR0: 80050033 > [98235.310129] CR2: c90001251000 CR3: 00021018d000 CR4: > 06f0 > [98235.312095] Call Trace: > [98235.314008] ? ZSTD_compressBlock_fast+0x94b/0xb30 > [98235.315975] ? ZSTD_compressContinue_internal+0x1a0/0x580 > [98235.317938] ? ZSTD_compressStream_generic+0x248/0x2f0 > [98235.319877] ? ZSTD_compressStream+0x41/0x60 > [98235.321821] ? zstd_compress_pages+0x236/0x5d0 > [98235.323724] ? btrfs_compress_pages+0x5e/0x80 > [98235.325684] ? compress_file_range.constprop.79+0x1eb/0x750 > [98235.327668] ? async_cow_start+0x2e/0x50 > [98235.329594] ? btrfs_worker_helper+0x1b9/0x1d0 > [98235.331486] ? process_one_work+0x158/0x2f0 > [98235.61] ? worker_thread+0x45/0x3a0 > [98235.335253] ? process_one_work+0x2f0/0x2f0 > [98235.337189] ? kthread+0x10e/0x130 > [98235.339020] ? kthread_park+0x60/0x60 > [98235.340819] ? ret_from_fork+0x22/0x30 > [98235.342637] Code: 8b 4e d0 4c 89 48 d0 4c 8b 4e d8 4c 89 48 d8 4c 8b 4e e0 > 4c 89 48 e0 4c 8b 4e e8 4c 89 48 e8 4c 8b 4e f0 4c 89 48 f0 4c 8b 4e f8 <4c> > 89 48 f8 48 39 f1 75 a2 4e 8d 04 c0 48 8b 31 48 83 c0 08 48 > [98235.346773] RIP: ZSTD_storeSeq.constprop.24+0x67/0xe0 RSP: c90007e5fa68 > [98235.348809] CR2: c90001251000 > [98235.363216] ---[ end trace 5fb3ad0f2aec0605 ]--- > [98235.363218] BUG: unable to handle kernel paging request at c9000393a000 > [98235.363239] IP: ZSTD_storeSeq.constprop.24+0x67/0xe0 > [98235.363241] PGD 227034067 > [98235.363242] P4D 227034067 > [98235.363243] PUD 227035067 > [98235.363244] PMD 21edec067 > [98235.363245] PTE 0 > (More of the above follows.) > > My reproducer copies an uncompressed tarball onto a fresh filesystem: > . > #!/bin/sh > set -e > > losetup -D; umount /mnt/vol1 ||: > dd if=/dev/zero of=/tmp/disk bs=2048 seek=1048575 count=1 > mkfs.btrfs -msingle /tmp/disk > losetup -f /tmp/disk > sleep 1 # yay udev races > mount -onoatime,compress=$1 /dev/loop0 /mnt/vol1 > time sh -c 'cp -p ~kilobyte/tmp/kernel.tar /mnt/vol1 && umount /mnt/vol1' > losetup -D > ` > (run it with arg of "zstd") > > Kernel is 4.12.0 + btrfs-for-4.13 + v4 of Qu's chunk check + some unrelated > stuff + zstd; in case it matters I've pushed my tree to > https://github.com/kilobyte/linux/tree/zstd-crash > > The payload is a tarball of the above, but, for debugging compression you > need the exact byte stream. https://angband.pl/tmp/kernel.tar.xz -- > without xz, I compressed it for transport. Thanks for the bug report Adam! I'm looking into the failure, and haven't been able to reproduce it yet. I've built my kernel from your tree, and I ran your script with the kernel.tar tarball 100 times, but haven't gotten a failure yet. I have a few questions to guide my debugging. - How many cores are you running with? I’ve run the script with 1, 2, and 4 cores. - Which version of gcc are you using to compile the kernel? I’m using gcc-6.2.0-5ubuntu12. - Are the failures always in exactly the same place, and does it fail 100% of the time or just regularly?
Re: tracing/kprobes: [Bug] Identical timestamps on two kprobes that are few instructions apart
Hi Steven, Thank you very much for your reply. I am using kernel - v4.12-rc3. I did something like this and see the issue: # trace-cmd record -e kprobes:s1 -e kprobes:s2 -- taskset -c 0 my_program # ./trace-cmd report -t --cpu 0 The issue is pretty intermittent and only happens when there are a lot of samples, and so "my_program" generates a few hundred threads. Any pointers on debugging this would be very helpful, or please let me know if you want me to collect any log messages. On Fri, Jul 7, 2017 at 12:01 PM, Steven Rostedt wrote: > On Fri, 7 Jul 2017 10:34:48 -0700 > Arun Kalyanasundaram wrote: > >> Hi, >> >> I am trying to use kprobes to time a few kernel functions. However, when I >> add two kprobes on a function that are a few instructions apart, I >> sometimes get the same timestamp (measured in nano seconds) on the two >> probes. >> >> For example, if I add the two probes as follows, >> 1) perf probe -a "kprobe1=__schedule" >> 2) perf probe -a "kprobe2=__schedule+12" >> >> I then use "perf record" on a multi-threaded benchmark (e.g. stream: >> https://www.cs.virginia.edu/stream/) to collect samples. I then see the >> same timestamp on kprobe1 and kprobe2 for the same thread running on the >> same CPU. Following is an example of the output showing the same timestamp >> on the two probes. >> >> comm,tid,cpu,time,event,ip,sym >> stream,62182,[064],3020935.384132080,probe:kprobe1,b36399f1,__schedule >> stream,62182,[064],3020935.384132080,probe:kprobe2,b36399fd,__schedule >> >> Since it happens intermittently, I am wondering if there is some sort of >> race condition here. Please let me know if this is an expected behavior or >> is there something wrong in the way I use kprobes. >> > > I don't see this with ftrace. What kernel are you using? > > # cd /sys/kernel/debug/tracing > # echo perf > trace_clock > # echo 'p:s1 __schedule' > kprobe_events > # echo 'p:s2 __schedule+12' >> kprobe_events > # echo 1 > events/kprobes/enable > # cd > # trace-cmd extract > # trace-cmd report -t --cpu 0 | less > > I didn't see anything where they had the same timestamps. > > > -- Steve
[PATCH v5] staging: lustre: lnet: remove dead code and useless wrapper
After removing commented out code, ksocknal_csum() becomes a useless
wrapper for crc32_le(). Remove it, and instead call crc32_le() directly.
Fixes the following checkpatch warning:
WARNING: space prohibited before semicolon
Signed-off-by: Dmitriy Cherkasov
---
v5:
- fix incomplete patch changelog
- improve code alignment
- reword commit message and summary to be more concise
v4:
- fix spacing issues
- fix typo in commit message
- add patch changelog
v3:
- fix spacing and alignment issues
(suggested by Joe Perches)
v2:
- remove ksocknal_csum() and call crc32_le() directly
(suggested by Greg KH)
- update commit message and summary to reflect these changes
drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h | 11 ---
.../staging/lustre/lnet/klnds/socklnd/socklnd_lib.c | 20 ++--
2 files changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
index 5540de6..9eb169d 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
@@ -519,17 +519,6 @@ struct ksock_proto {
#define CPU_MASK_NONE 0UL
#endif
-static inline __u32 ksocknal_csum(__u32 crc, unsigned char const *p, size_t
len)
-{
-#if 1
- return crc32_le(crc, p, len);
-#else
- while (len-- > 0)
- crc = ((crc + 0x100) & ~0xff) | ((crc + *p++) & 0xff) ;
- return crc;
-#endif
-}
-
static inline int
ksocknal_route_mask(void)
{
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
index 8a036f4..9c328dc 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
@@ -201,9 +201,9 @@
if (fragnob > sum)
fragnob = sum;
- conn->ksnc_rx_csum = ksocknal_csum(conn->ksnc_rx_csum,
- iov[i].iov_base,
- fragnob);
+ conn->ksnc_rx_csum = crc32_le(conn->ksnc_rx_csum,
+ iov[i].iov_base,
+ fragnob);
}
conn->ksnc_msg.ksm_csum = saved_csum;
}
@@ -243,8 +243,8 @@
if (fragnob > sum)
fragnob = sum;
- conn->ksnc_rx_csum = ksocknal_csum(conn->ksnc_rx_csum,
- base, fragnob);
+ conn->ksnc_rx_csum = crc32_le(conn->ksnc_rx_csum,
+ base, fragnob);
kunmap(kiov[i].bv_page);
}
@@ -265,22 +265,22 @@
tx->tx_msg.ksm_csum = 0;
- csum = ksocknal_csum(~0, tx->tx_iov[0].iov_base,
-tx->tx_iov[0].iov_len);
+ csum = crc32_le(~0, tx->tx_iov[0].iov_base,
+ tx->tx_iov[0].iov_len);
if (tx->tx_kiov) {
for (i = 0; i < tx->tx_nkiov; i++) {
base = kmap(tx->tx_kiov[i].bv_page) +
tx->tx_kiov[i].bv_offset;
- csum = ksocknal_csum(csum, base, tx->tx_kiov[i].bv_len);
+ csum = crc32_le(csum, base, tx->tx_kiov[i].bv_len);
kunmap(tx->tx_kiov[i].bv_page);
}
} else {
for (i = 1; i < tx->tx_niov; i++)
- csum = ksocknal_csum(csum, tx->tx_iov[i].iov_base,
-tx->tx_iov[i].iov_len);
+ csum = crc32_le(csum, tx->tx_iov[i].iov_base,
+ tx->tx_iov[i].iov_len);
}
if (*ksocknal_tunables.ksnd_inject_csum_error) {
--
1.9.1
Re: [PATCH] printk: Modify operators of printed_len
On Sat, 2017-07-08 at 04:32 +0800, pierre kuo wrote: > hi Joe: Hello Pierre. > 2017-07-08 1:12 GMT+08:00 Joe Perches : > > On Sat, 2017-07-08 at 00:30 +0800, Pierre Kuo wrote: > > > In 8b1742c9c207, we remove printk-recursion detection code in > > > vprintk_emit(), where it is the first place that printed_len calculated. > > > After removing above detection, it seems we can directly assign the > > > result of log_output to printed_len. > > > > [] > > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > > > > [] > > > @@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int level, > > > if (dict) > > > lflags |= LOG_PREFIX|LOG_NEWLINE; > > > > > > - printed_len += log_output(facility, level, lflags, dict, dictlen, > > > text, text_len); > > > + printed_len = log_output(facility, level, lflags, dict, dictlen, > > > text, text_len); > > > > If this is appropriate, this should also remove the > > initialization of printed_len and perhaps rename it too. > > I cannot quite understand the reason why need to rename. > printed_len seems meet the meaning we expect for here. Verbosity. To me, len would be adequate. Anyway, the real point was the declaration of printed_len could remove the " = 0" as it's now only set once. cheers, Joe
Re: [RFC PATCH v1 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE
On Fri, Jul 7, 2017 at 3:15 PM, Steven Rostedt wrote: > On Fri, 7 Jul 2017 15:07:09 -0700 > Joel Fernandes wrote: > > >> > It is rather long. Although I actually hate the SUGOV, it is easily >> > grepable. Just comment what it stands for. We can always change it >> > later. >> >> I was thinking why not just SCHED_FLAG_CPUFREQ. That says its for >> cpufreq purposes, and is a bit self-documenting. "WORKER" is a bit >> redundant and can be dropped in my opinion. > > I was thinking that too, but was wondering how tightly coupled is this > with SCHED_DEADLINE? I like the searchability of SUGOV, where as > CPUFREQ is still quite broad. Yes this is tightly coupled with DL so in that case probably a more specific name is better as you mentioned. thanks, -Joel
Re: [git pull] vfs.git part 1
Linus Torvalds writes: > On Fri, Jul 7, 2017 at 8:59 AM, Linus Torvalds > wrote: >> >>> Patch coming. >> >> I'm not seeing a patch, so I did my own. But it's _entirely_ untested. >> Does the attached fix things for you? > > Oh, I see you sent a patch to the list but didn't cc me like in this thread. Oops, I sent it To you, but I forgot to make it a reply to this thread which was daft. cheers
Re: [git pull] vfs.git part 1
Linus Torvalds writes: > On Fri, Jul 7, 2017 at 8:59 AM, Linus Torvalds > wrote: >> >> The copy_flock_fields() macro has the arguments in order , >> but all the users seem to do it the other way around. > > Looking more at it, I think I'd also like copy_flock_fields() to take > pointer arguments, to match all the code around it (both > copy_to/from_user and the memset calls. > > The actual order of arguments I suspect Michael's patch did better - > make the copy_flock_fields() just match the order of memcpy() and > copy_to/from_user(), both of which have order. > > So I think my preferred patch would be something like this, even if it > is bigger than either. > > Comments? Michael, does this work for your case? Yeah that works, as committed in your tree. Sorry for the slow reply, our time zones don't line up all that well :) cheers
Re: [GIT PULL] MFD for v4.13
On Fri, 07 Jul 2017, Linus Torvalds wrote: > On Fri, Jul 7, 2017 at 2:50 AM, Lee Jones wrote: > > > > include/linux/mfd/madera/registers.h | 8832 > > > > So I've pulled everything but this, because honestly, that file looks > like utter garbage. > > Why are there all those _hundreds_ of odd defines for > > MADERA_WSEQ_SEQUENCE_xx > > when it looks like you could just do one single one: > > // The sequence is one-based because somebody doesn't > // know that indices start at 0. Thus the "-2". > #define MADERA_WSEQ_SEQUENCE(x) (0x3000 + (x)*2 - 2) > > and similar things go for for pretty much EVERY SINGLE LINE in that > 8-thousand line piece of nasty horrible crud. > > Being auto-generated doesn't really make this kind of thing any > better. In fact, it makes it worse, because those stupid hardcoded > names are often *harder* to use, because you cannot use a variable to > index into things (which you may often want). > > So we have eight thousand lines of garbage that is > > (a) probably closer to 200x too many lines > (b) less flexible than doing it right > > Honestly, tell me why would I want to merge something monstrous like that? I'm inclined to agree and had my reservations. However based on a previous conversation [0], I was convinced that it's actually the right thing to do. https://lkml.org/lkml/2017/4/7/229 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v6 1/4] firmware: scm: Add new SCM call API for switching memory ownership
On 06/22, Avaneesh Kumar Dwivedi wrote:
> diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
> index 6e6d561..cdfe986 100644
> --- a/drivers/firmware/qcom_scm-64.c
> +++ b/drivers/firmware/qcom_scm-64.c
> @@ -292,6 +304,86 @@ int qcom_scm_pas_shutdown(u32 peripheral)
> }
> EXPORT_SYMBOL(qcom_scm_pas_shutdown);
>
> +/**
> + * qcom_scm_assign_mem() - Make a secure call to reassign memory ownership
> + *
> + * @mem_addr: mem region whose ownership need to be reassigned
> + * @mem_sz: size of the region.
> + * @srcvm:vmid for current set of owners, each set bit in
> + *flag indicate a unique owner
> + * @newvm:array having new owners and corrsponding permission
> + *flags
> + * @dest_cnt: number of owners in next set.
> + * Return next set of owners on success.
> + */
> +int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, int srcvm,
> + struct qcom_scm_vmperm *newvm, int dest_cnt)
> +{
> + unsigned long dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
Why do we need this? Just curious if we can drop this.
> + struct qcom_scm_current_perm_info *destvm;
> + struct qcom_scm_mem_map_info *mem;
> + phys_addr_t memory_phys;
> + phys_addr_t dest_phys;
> + phys_addr_t src_phys;
> + size_t mem_all_sz;
> + size_t memory_sz;
> + size_t dest_sz;
> + size_t src_sz;
> + int next_vm;
> + __le32 *src;
> + void *ptr;
> + int ret;
> + int len;
> + int i;
> +
> + src_sz = hweight_long(srcvm) * sizeof(*src);
> + memory_sz = sizeof(*mem);
> + dest_sz = dest_cnt*sizeof(*destvm);
> + mem_all_sz = src_sz + memory_sz + dest_sz;
> +
> + ptr = dma_alloc_attrs(__scm->dev, ALIGN(mem_all_sz, SZ_64),
> + &src_phys, GFP_KERNEL, dma_attrs);
> + if (!ptr)
> + return -ENOMEM;
> +
> + /* Fill source vmid detail */
> + src = (__le32 *)ptr;
Cast is necessary?
> + len = hweight_long(srcvm);
> + for (i = 0; i < len; i++) {
> + src[i] = cpu_to_le32(ffs(srcvm) - 1);
> + srcvm ^= 1 << (ffs(srcvm) - 1);
> + }
> +
> + /* Fill details of mem buff to map */
> + mem = ptr + ALIGN(src_sz, SZ_64);
> + memory_phys = src_phys + ALIGN(src_sz, SZ_64);
> + mem[0].mem_addr = cpu_to_le64(mem_addr);
> + mem[0].mem_size = cpu_to_le64(mem_sz);
> +
> + next_vm = 0;
> + /* Fill details of next vmid detail */
> + destvm = ptr + ALIGN(memory_sz, SZ_64) + ALIGN(src_sz, SZ_64);
> + dest_phys = memory_phys + ALIGN(memory_sz, SZ_64);
> + for (i = 0; i < dest_cnt; i++) {
> + destvm[i].vmid = cpu_to_le32(newvm[i].vmid);
> + destvm[i].perm = cpu_to_le32(newvm[i].perm);
> + destvm[i].ctx = 0;
> + destvm[i].ctx_size = 0;
> + next_vm |= BIT(newvm[i].vmid);
> + }
> +
> + ret = __qcom_scm_assign_mem(__scm->dev, memory_phys,
> + memory_sz, src_phys, src_sz, dest_phys, dest_sz);
> + dma_free_attrs(__scm->dev, ALIGN(mem_all_sz, SZ_64),
> + ptr, src_phys, dma_attrs);
> + if (ret == 0)
> + return next_vm;
> + else if (ret > 0)
> + return -ret;
This still confuses me. Do we really just pass whatever the
firmware tells us the error code is up to the caller? Shouldn't
we be remapping the scm errors we receive to normal linux errnos?
> + return ret;
> +}
> +EXPORT_SYMBOL(qcom_scm_assign_mem);
> +
> static int qcom_scm_pas_reset_assert(struct reset_controller_dev *rcdev,
>unsigned long idx)
> {
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
