Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU
Hi Nicolas,
On 21/07/16 05:22, Nicolas Pitre wrote:
> This series provides the necessary changes to allow "flat" executable
> binaries meant for no-MMU systems to actually run on systems with a MMU.
> Also thrown in are various cleanups to binfmt_flat.c.
I got to the bottom of why I couldn't run m68k flat binaries on
an MMU enabled m68k system. I had to fix the regs setup, with the
patch below. With this I can now run flat binaries on my ColdFire
MMU enabled system.
This change is completely independent of your patch series so I'll
push this separately via the linux-m68k list and my m68knommu git
tree.
Regards
Greg
Subject: [PATCH] m68k: fix bFLT executable running on MMU enabled systems
Even after recent changes to support running flat format executables on
MMU enabled systems (by nicolas.pi...@linaro.org) they still failed to
run on m68k/ColdFire MMU enabled systems. On trying to run a flat format
binary the application would immediately crash with a SIGSEGV.
Code to setup the D5 register with the base of the application data
region was only in the non-MMU code path, so it was not being set for
the MMU enabled case. Flat binaries on m68k/ColdFire use this to support
GOT/PIC flat built application code.
Fix this so that D5 is always setup when loading/running a bFLT executable
on m68k systems.
Signed-off-by: Greg Ungerer
---
arch/m68k/include/asm/flat.h | 6 ++
arch/m68k/include/asm/processor.h | 2 --
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/include/asm/flat.h b/arch/m68k/include/asm/flat.h
index f3f592d..a97c479 100644
--- a/arch/m68k/include/asm/flat.h
+++ b/arch/m68k/include/asm/flat.h
@@ -19,4 +19,10 @@ static inline int flat_set_persistent(unsigned long relval,
return 0;
}
+#define FLAT_PLAT_INIT(regs) \
+ do { \
+ if (current->mm) \
+ (regs)->d5 = current->mm->start_data; \
+ } while (0)
+
#endif /* __M68KNOMMU_FLAT_H__ */
diff --git a/arch/m68k/include/asm/processor.h
b/arch/m68k/include/asm/processor.h
index a6ce2ec..46672d1 100644
--- a/arch/m68k/include/asm/processor.h
+++ b/arch/m68k/include/asm/processor.h
@@ -131,8 +131,6 @@ extern int handle_kernel_fault(struct pt_regs *regs);
do {\
(_regs)->pc = (_pc);\
setframeformat(_regs); \
- if (current->mm)\
- (_regs)->d5 = current->mm->start_data; \
(_regs)->sr &= ~0x2000; \
wrusp(_usp);\
} while(0)
--
1.9.1
linux-next: Tree for Jul 21
Hi all, Changes since 20160720: The xfs tree gained a conflict against Linus' tree. The net-next tree gained a conflict against the net tree. The l2-mtd tree lost its build failure. The crypto tree lost its build failure. The kspp tree gained a conflict against the arm64 tree. The block tree gained a conflict against Linus' tree. The device-mapper tree gained a conflict against the block tree. The kvm tree gained a conflict against the powerpc tree. The nvdimm tree gained a build failure so I used the version from next-20160720. The akpm tree lost a patch that turned up elsewhere. Non-merge commits (relative to Linus' tree): 10587 9749 files changed, 534253 insertions(+), 187882 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 239 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (47ef4ad2684d Merge tag 'for-linus-20160715' of git://git.infradead.org/linux-mtd) Merging fixes/master (5edb56491d48 Linux 4.7-rc3) Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported variables) Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if DW2_UNWIND is disabled) Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 errata initialization) Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs for v4.7-rc2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (bfa37087aa04 powerpc: Initialise pci_io_base as early as possible) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (6b15d6650c53 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (882b0f2fba83 net/mlx5e: Fix del vxlan port command buffer memset) Merging ipsec/master (1ba5bf993c6a xfrm: fix crash in XFRM_MSG_GETSA netlink handler) Merging netfilter/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging ipvs/master (3777ed688fba ipvs: fix bind to link-local mcast IPv6 address in backup) Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git) Merging mac80211/master (16a910a6722b cfg80211: handle failed skb allocation) Merging sound-current/for-linus (76df52969711 ALSA: usb-audio: Fix quirks code is not called) Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC code) Merging driver-core.current/driver-core-linus (92d21ac74a9e Linux 4.7-rc7) Merging tty.current/tty-linus (a99cde438de0 Linux 4.7-rc6) Merging usb.current/usb-linus (a99cde438de0 Linux 4.7-rc6) Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command) Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5) Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: otg-fsm: add license to usb-otg-fsm) Merging staging.current/staging-linus (a99cde438de0 Linux 4.7-rc6) Merging char-misc.current/char-misc-linus (33688abb2802 Linux 4.7-rc4) Merging input-current/for-linus (6a5029e66404 Input: ts4800-ts - add missing of_node_put after calling of_parse_phandle) Merging crypto-current/master (055ddaace035 crypto: user - re-add size check for CRYPTO_MSG_GETALG) Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/li
Re: [PATCH V2 2/2] mmc: tegra: Only advertise UHS modes if IO regulator is present
On 12/07/16 16:53, Jon Hunter wrote:
> To support UHS modes for Tegra an external regulator must be present
> to adjust the IO voltage accordingly. Even if the regulator is not
> present but the host supports the UHS modes and the device supports the
> UHS modes, then we will attempt to switch to a high-speed mode. Without
> an external regulator, Tegra will fail to switch to the high-speed
> mode.
>
> It has been found that with some SD cards, that once it has been switch
> to operate at a high-speed mode, all subsequent commands issues to the
> card will fail and so it will not be possible to switch back to a non
> high-speed mode and so the SD card initialisation will fail.
>
> The SDHCI core does not require that the host have an external regulator
> when switching to UHS modes and therefore, the Tegra SDHCI host
> controller should only advertise the UHS modes as being supported if the
> regulator for the IO voltage is present. Fortunately, Tegra has a vendor
> specific register which can be used to control which modes are
> advertised via the SDHCI_CAPABILITIES register. Hence, if there is no IO
> voltage regulator available for the Tegra SDHCI host, then don't
> advertise the UHS modes.
>
> Note that if the regulator is not available, we also don't advertise that
> the SDHCI is compatible with v3.0 of the SDHCI specification because
> this will read the SDHCI_CAPABILITIES_1 register which will enable other
> UHS modes.
>
> This fixes commit 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes") which
> enables UHS mode without checking if the board can support them.
>
> Fixes: 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes")
>
> Signed-off-by: Jon Hunter
Acked-by: Adrian Hunter
> ---
> drivers/mmc/host/sdhci-tegra.c | 49
> +-
> 1 file changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index bcc0de47fe7e..bd1199825f9f 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -148,28 +148,37 @@ static void tegra_sdhci_reset(struct sdhci_host *host,
> u8 mask)
> return;
>
> misc_ctrl = sdhci_readl(host, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> - /* Erratum: Enable SDHCI spec v3.00 support */
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
> - misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
> - /* Advertise UHS modes as supported by host */
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_SDR50)
> - misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDR50;
> - else
> - misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR50;
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_DDR50)
> - misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_DDR50;
> - else
> - misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_DDR50;
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_SDR104)
> - misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDR104;
> - else
> - misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR104;
> - sdhci_writel(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> -
> clk_ctrl = sdhci_readl(host, SDHCI_TEGRA_VENDOR_CLOCK_CTRL);
> +
> + misc_ctrl &= ~(SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300 |
> +SDHCI_MISC_CTRL_ENABLE_SDR50 |
> +SDHCI_MISC_CTRL_ENABLE_DDR50 |
> +SDHCI_MISC_CTRL_ENABLE_SDR104);
> +
> clk_ctrl &= ~SDHCI_CLOCK_CTRL_SPI_MODE_CLKEN_OVERRIDE;
> - if (soc_data->nvquirks & SDHCI_MISC_CTRL_ENABLE_SDR50)
> - clk_ctrl |= SDHCI_CLOCK_CTRL_SDR50_TUNING_OVERRIDE;
> +
> + /*
> + * If the board does not define a regulator for the SDHCI
> + * IO voltage, then don't advertise support for UHS modes
> + * even if the device supports it because the IO voltage
> + * cannot be configured.
> + */
> + if (!IS_ERR(host->mmc->supply.vqmmc)) {
> + /* Erratum: Enable SDHCI spec v3.00 support */
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
> + misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
> + /* Advertise UHS modes as supported by host */
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_SDR50)
> + misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDR50;
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_DDR50)
> + misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_DDR50;
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_SDR104)
> + misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDR104;
> + if (soc_data->nvquirks & SDHCI_MISC_CTRL_ENABLE_SDR50)
> + clk_ctrl |= SDHCI_CLOCK_CTRL_SDR50_TUNING_OVERRIDE;
> + }
> +
> + sdhci_writel(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> sdhci_writel(host, clk_ctrl, SDHCI_TEGRA_VENDOR_CLOCK_CTRL);
>
> if (soc_data->nvquirks & NVQUIRK_HAS_PADCALIB)
>
Re: [PATCH] leds/trigger/cpu: move from CPU_STARTING to ONLINE level
Hi Sebastian,
On 07/20/2016 05:24 PM, Sebastian Andrzej Siewior wrote:
There is no need the ledtriger to be called *that* early in the hotplug
process (+ with disabled interrupts). As explained by Jacek Anaszewski [0]
there is no need for it.
Therefore this patch moves it to the ONLINE/PREPARE_DOWN level using the
dynamic registration for the id.
[0] https://lkml.kernel.org/r/578c92bc.2070...@samsung.com
Cc: Jacek Anaszewski
Cc: Linus Torvalds
Cc: Linus Walleij
Cc: Paul Gortmaker
Cc: Peter Zijlstra
Cc: Richard Purdie
Cc: Thomas Gleixner
Cc: linux-l...@vger.kernel.org
Cc: r...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/leds/trigger/ledtrig-cpu.c | 16
include/linux/cpuhotplug.h | 1 -
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/leds/trigger/ledtrig-cpu.c
b/drivers/leds/trigger/ledtrig-cpu.c
index 4a6a182d0a88..22f0634dd3fa 100644
--- a/drivers/leds/trigger/ledtrig-cpu.c
+++ b/drivers/leds/trigger/ledtrig-cpu.c
@@ -92,13 +92,13 @@ static struct syscore_ops ledtrig_cpu_syscore_ops = {
.resume = ledtrig_cpu_syscore_resume,
};
-static int ledtrig_starting_cpu(unsigned int cpu)
+static int ledtrig_online_cpu(unsigned int cpu)
{
ledtrig_cpu(CPU_LED_START);
return 0;
}
-static int ledtrig_dying_cpu(unsigned int cpu)
+static int ledtrig_prepare_down_cpu(unsigned int cpu)
{
ledtrig_cpu(CPU_LED_STOP);
return 0;
@@ -107,6 +107,7 @@ static int ledtrig_dying_cpu(unsigned int cpu)
static int __init ledtrig_cpu_init(void)
{
int cpu;
+ int ret;
/* Supports up to cpu cores */
BUILD_BUG_ON(CONFIG_NR_CPUS > );
@@ -126,12 +127,11 @@ static int __init ledtrig_cpu_init(void)
register_syscore_ops(&ledtrig_cpu_syscore_ops);
- /*
-* FIXME: Why needs this to happen in the interrupt disabled
-* low level bringup phase of a cpu?
-*/
- cpuhp_setup_state(CPUHP_AP_LEDTRIG_STARTING, "AP_LEDTRIG_STARTING",
- ledtrig_starting_cpu, ledtrig_dying_cpu);
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "AP_LEDTRIG_STARTING",
+ ledtrig_online_cpu, ledtrig_prepare_down_cpu);
+ if (ret < 0)
+ pr_err("CPU hotplug notifier for ledtrig-cpu could not be
registered: %d\n",
+ ret);
pr_info("ledtrig-cpu: registered to indicate activity on CPUs\n");
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 09ef54bcba39..282800b42627 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -65,7 +65,6 @@ enum cpuhp_state {
CPUHP_AP_ARM_CORESIGHT_STARTING,
CPUHP_AP_ARM_CORESIGHT4_STARTING,
CPUHP_AP_ARM64_ISNDEP_STARTING,
- CPUHP_AP_LEDTRIG_STARTING,
CPUHP_AP_SMPCFD_DYING,
CPUHP_AP_X86_TBOOT_DYING,
CPUHP_AP_NOTIFY_STARTING,
Acked-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
Re: [PATCH V2 1/2] mmc: sdhci: Request regulators before reading capabilities
On 20/07/16 16:04, Adrian Hunter wrote:
> On 20/07/16 16:02, Adrian Hunter wrote:
>> On 12/07/16 16:53, Jon Hunter wrote:
>>> The capabilities of the SDHCI host controller are read early during the
>>> SDHCI host initialisation in sdhci_setup_host() and before any
>>> regulators for the host have been requested. This means that if the host
>>> supports some high-speed modes (according to its capabilities register),
>>> but the board cannot because the appropriate voltage regulator is not
>>> available, then the host cannot easily override the capabilities that
>>> are supported.
>>>
>>> To allow a SDHCI host controller to determine if it can support high
>>> speed modes via the presense of the MMC regulators, request the
>>
>> Try not to confuse High Speed mode with UHS modes.
>>
>> presense -> presence
>>
>>> regulators before reading the capabilites of the host controller. This
>>
>> capabilites -> capabilities
>>
>>> will allow the SDHCI host to use the 'reset' callback to take the
>>> appropriate action (set flags, configure registers, etc) before the
>>> capabilities register(s) are read.
>>>
>>> Please note that some SDHCI hosts, such as the Tegra SDHCI host, has
>>> the ability to mask bits in the capabilities register to prevent
>>> certain capabilities from being advertised.
>>>
>>> Signed-off-by: Jon Hunter
>>> ---
>>>
>>> Although this is described as a "V2" this patch has been added since
>>> the original patch was posted.
>>>
>>> If the below is deemed not appropriate, then another solution I was
>>> thinking of is to allow the SDHCI host to call 'mmc_regulator_get_supply'
>>> before calling sdhci_setup_host() and then in sdhci_setup_host() check
>>> if any regulators are already present before calling
>>> mmc_regulator_get_supply().
>>
>> And we can still do that later if we need to.
>>
>>>
>>> drivers/mmc/host/sdhci.c | 16 +++-
>>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 2ee8bfa77116..628c4b3558c0 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -3021,6 +3021,17 @@ int sdhci_setup_host(struct sdhci_host *host)
>>>
>>> mmc = host->mmc;
>>>
>>> + /*
>>> +* If there are external regulators, get them. Note
>>> +* this must be done early before resetting the host
>>> +* and reading the capabilities so that the host can
>>> +* take the appropriate action if regulators are not
>>> +* available.
>
> Also you could spread this comment out to 80 columns.
>
>>> +*/
>>> + ret = mmc_regulator_get_supply(mmc);
>>> + if (ret == -EPROBE_DEFER)
>>> + return ret;
>>> +
>>> sdhci_read_caps(host);
>>>
>>> override_timeout_clk = host->timeout_clk;
>>> @@ -3253,11 +3264,6 @@ int sdhci_setup_host(struct sdhci_host *host)
>>> mmc_gpio_get_cd(host->mmc) < 0)
>>> mmc->caps |= MMC_CAP_NEEDS_POLL;
>>>
>>> - /* If there are external regulators, get them */
>>> - ret = mmc_regulator_get_supply(mmc);
>>> - if (ret == -EPROBE_DEFER)
>>> - goto undma;
>>
>> All goto's before this now need to goto unreg.
Er, actually they don't!
So apart from the cosmetics above:
Acked-by: Adrian Hunter
>>
>>> -
>>> /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
>>> if (!IS_ERR(mmc->supply.vqmmc)) {
>>> ret = regulator_enable(mmc->supply.vqmmc);
>>>
>>
>>
>
>
Re: v4.1 to v4.7: regression in tsc2005 driver
On Thu, Jul 21, 2016 at 08:32:34AM +0200, Pavel Machek wrote: > Hi! > > > > In the mean time you can adjust the name or use XID instead. > > > > X has partially fixed this a few years ago. All input drivers (that > > matter) export a Device Node property that sets the device node for each > > device. > > > > $ xinput list-props "SynPS/2 Synaptics TouchPad" | grep "Device Node" > > Device Node (261): "/dev/input/event4" > > > > Based on that you can get the udev device and work your way into any of the > > sysfs tree. Or do whatever else you want. > > > > But other than that there isn't anything in X to fix. xinput is primarily a > > debugging tool and it does name resolution for convenience. But it's not a > > tool for complex configurations. It does exactly what it needs to do, if you > > need something that's more complicated and relies on information not > > available to the X device itself then you'll need to write a custom tool > > that does what you need. sorry. > > Ok.. so out of the box, touchscreen is "upside down" and miscalibrated > on n900. So I need to run > > xinput --set-prop --type=float 8 115 1.10 0.00 -0.05 0.00 1.18 -0.10 0.00 > 0.00 1.00 > xinput --set-prop --type=int 8 249 0 1 > > (or equivalent with names) so that I can use the touchscreen. (And > that's quite important -- X is somehow unusable without pointing > device). > > If xinput is not the right solution, what is the right solution? if it's reliably miscalibrated (i.e. the numbers don't change), use an xorg.conf snippet. If it needs some run-time changes add the hooks to whatever does the calibration. the X api itself is trivial, you can lift it from xinput. fwiw, you don't need to specify the type, in fact it's better not to because then libinput will just pick the right type anyway (or complain in case of mismatch). Cheers, Peter
Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen
On Thu, Jul 21, 2016 at 08:29:50AM +0200, Maxime Ripard wrote:
> On Wed, Jul 20, 2016 at 10:29:10AM +0200, Quentin Schulz wrote:
> > + irq = regmap_irq_get_virq(sunxi_gpadc_mfd_dev->regmap_irqc, irq);
> > + ret = devm_request_any_context_irq(&pdev->dev, irq,
> > + sunxi_gpadc_tp_up_irq_handler, 0,
> > + "tp_up", info);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev,
> > + "could not request TP_UP_PENDING interrupt: %d\n", ret);
> > + goto err;
> > + }
>
> You enable the interrupts...
>
> > + info->tp_up_irq = irq;
> > + disable_irq(irq);
> > +
> > + ret = input_register_device(input);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to register input device\n");
> > + goto err;
> > + }
>
> ... but your driver isn't registered yet. How does input_report and
> input_sync behave in such a case?
This is explicitly allowed:
"
...
* NOTE: input_event() may be safely used right after input device was
* allocated with input_allocate_device(), even before it is registered
* with input_register_device(), but the event will not reach any of the
* input handlers. Such early invocation of input_event() may be used
* to 'seed' initial state of a switch or initial position of absolute
* axis, etc.
*/
"
Thanks.
--
Dmitry
Re: [PATCH v2 2/5] locking/pvqspinlock: Fix missed PV wakeup problem
On 2016年07月16日 00:35, Peter Zijlstra wrote:
On Fri, Jul 15, 2016 at 12:07:03PM +0200, Peter Zijlstra wrote:
So if we are kicked by the unlock_slowpath, and the lock is stealed by
someone else, we need hash its node again and set l->locked to
_Q_SLOW_VAL, then enter pv_wait.
Right, let me go think about this a bit.
Urgh, brain hurt.
So I _think_ the below does for it but I could easily have missed yet
another case.
Waiman's patch has the problem that it can have two pv_hash() calls for
the same lock in progress and I'm thinking that means we can hit the
BUG() in pv_hash() due to that.
If we can't, it still has a problem because its not telling us either.
--- a/kernel/locking/qspinlock_paravirt.h
+++ b/kernel/locking/qspinlock_paravirt.h
@@ -20,7 +20,8 @@
* native_queued_spin_unlock().
*/
-#define _Q_SLOW_VAL(3U << _Q_LOCKED_OFFSET)
+#define _Q_HASH_VAL(3U << _Q_LOCKED_OFFSET)
+#define _Q_SLOW_VAL(7U << _Q_LOCKED_OFFSET)
/*
* Queue Node Adaptive Spinning
@@ -36,14 +37,11 @@
*/
#define PV_PREV_CHECK_MASK0xff
-/*
- * Queue node uses: vcpu_running & vcpu_halted.
- * Queue head uses: vcpu_running & vcpu_hashed.
- */
enum vcpu_state {
- vcpu_running = 0,
- vcpu_halted,/* Used only in pv_wait_node */
- vcpu_hashed,/* = pv_hash'ed + vcpu_halted */
+ vcpu_node_running = 0,
+ vcpu_node_halted,
+ vcpu_head_running,
+ vcpu_head_halted,
};
struct pv_node {
@@ -263,7 +261,7 @@ pv_wait_early(struct pv_node *prev, int
if ((loop & PV_PREV_CHECK_MASK) != 0)
return false;
- return READ_ONCE(prev->state) != vcpu_running;
+ return READ_ONCE(prev->state) & 1;
}
/*
@@ -311,20 +309,19 @@ static void pv_wait_node(struct mcs_spin
*
* Matches the cmpxchg() from pv_kick_node().
*/
- smp_store_mb(pn->state, vcpu_halted);
+ smp_store_mb(pn->state, vcpu_node_halted);
- if (!READ_ONCE(node->locked)) {
- qstat_inc(qstat_pv_wait_node, true);
- qstat_inc(qstat_pv_wait_early, wait_early);
- pv_wait(&pn->state, vcpu_halted);
- }
+ if (READ_ONCE(node->locked))
+ return;
+
+ qstat_inc(qstat_pv_wait_node, true);
+ qstat_inc(qstat_pv_wait_early, wait_early);
+ pv_wait(&pn->state, vcpu_node_halted);
/*
-* If pv_kick_node() changed us to vcpu_hashed, retain that
-* value so that pv_wait_head_or_lock() knows to not also try
-* to hash this lock.
+* If pv_kick_node() advanced us, retain that state.
*/
- cmpxchg(&pn->state, vcpu_halted, vcpu_running);
+ cmpxchg(&pn->state, vcpu_node_halted, vcpu_node_running);
/*
* If the locked flag is still not set after wakeup, it is a
@@ -362,18 +359,17 @@ static void pv_kick_node(struct qspinloc
*
* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
*/
- if (cmpxchg(&pn->state, vcpu_halted, vcpu_hashed) != vcpu_halted)
+ if (cmpxchg(&pn->state, vcpu_node_halted, vcpu_head_running) !=
vcpu_node_halted)
well, I think it should be
if (cmpxchg(&pn->state, vcpu_node_halted, vcpu_head_halted) != vcpu_node_halted)
yes, the node has been the *head*, but the running state does not change.
others looks ok to me.
return;
/*
-* Put the lock into the hash table and set the _Q_SLOW_VAL.
-*
-* As this is the same vCPU that will check the _Q_SLOW_VAL value and
-* the hash table later on at unlock time, no atomic instruction is
-* needed.
+* See pv_wait_head_or_lock(). We have to hash and force the unlock
+* into the slow path to deliver the actual kick for waking.
*/
- WRITE_ONCE(l->locked, _Q_SLOW_VAL);
- (void)pv_hash(lock, pn);
+ if (cmpxchg(&l->locked, _Q_LOCKED_VAL, _Q_HASH_VAL) == _Q_LOCKED_VAL) {
+ (void)pv_hash(lock, pn);
+ smp_store_release(&l->locked, _Q_SLOW_VAL);
+ }
}
/*
@@ -388,28 +384,22 @@ pv_wait_head_or_lock(struct qspinlock *l
{
struct pv_node *pn = (struct pv_node *)node;
struct __qspinlock *l = (void *)lock;
- struct qspinlock **lp = NULL;
int waitcnt = 0;
int loop;
/*
-* If pv_kick_node() already advanced our state, we don't need to
-* insert ourselves into the hash table anymore.
-*/
- if (READ_ONCE(pn->state) == vcpu_hashed)
- lp = (struct qspinlock **)1;
-
- /*
* Tracking # of slowpath locking operations
*/
qstat_inc(qstat_pv_lock_slowpath, true);
for (;; waitcnt++) {
+ u8 locked;
+
Re: [PATCH 3.12 28/88] netfilter: x_tables: validate targets of jumps
On 07/14/2016, 10:15 AM, Jiri Slaby wrote:
> From: Florian Westphal
>
> 3.12-stable review patch. If anyone has any objections, please let me know.
>
> ===
>
> commit 36472341017529e2b12573093cc0f68719300997 upstream.
I am now dropping this one. 3.12.62 will be released without that patch.
After the performance issue is resolved, it will be requeued.
> When we see a jump also check that the offset gets us to beginning of
> a rule (an ipt_entry).
>
> The extra overhead is negible, even with absurd cases.
>
> 300k custom rules, 300k jumps to 'next' user chain:
> [ plus one jump from INPUT to first userchain ]:
>
> Before:
> real0m24.874s
> user0m7.532s
> sys 0m16.076s
>
> After:
> real0m27.464s
> user0m7.436s
> sys 0m18.840s
>
> Signed-off-by: Florian Westphal
> Signed-off-by: Pablo Neira Ayuso
> Signed-off-by: Jiri Slaby
> ---
> net/ipv4/netfilter/arp_tables.c | 17 +
> net/ipv4/netfilter/ip_tables.c | 17 +
> net/ipv6/netfilter/ip6_tables.c | 17 +
> 3 files changed, 51 insertions(+)
>
> diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
> index 7460b7bef3ab..473ec559ce7b 100644
> --- a/net/ipv4/netfilter/arp_tables.c
> +++ b/net/ipv4/netfilter/arp_tables.c
> @@ -358,6 +358,19 @@ static inline bool unconditional(const struct arpt_entry
> *e)
> memcmp(&e->arp, &uncond, sizeof(uncond)) == 0;
> }
>
> +static bool find_jump_target(const struct xt_table_info *t,
> + const void *entry0,
> + const struct arpt_entry *target)
> +{
> + struct arpt_entry *iter;
> +
> + xt_entry_foreach(iter, entry0, t->size) {
> + if (iter == target)
> + return true;
> + }
> + return false;
> +}
> +
> /* Figures out from what hook each rule can be called: returns 0 if
> * there are loops. Puts hook bitmask in comefrom.
> */
> @@ -451,6 +464,10 @@ static int mark_source_chains(const struct xt_table_info
> *newinfo,
> /* This a jump; chase it. */
> duprintf("Jump rule %u -> %u\n",
>pos, newpos);
> + e = (struct arpt_entry *)
> + (entry0 + newpos);
> + if (!find_jump_target(newinfo, entry0,
> e))
> + return 0;
> } else {
> /* ... this is a fallthru */
> newpos = pos + e->next_offset;
> diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
> index 8fc22eed9603..dba9d8070d07 100644
> --- a/net/ipv4/netfilter/ip_tables.c
> +++ b/net/ipv4/netfilter/ip_tables.c
> @@ -434,6 +434,19 @@ ipt_do_table(struct sk_buff *skb,
> #endif
> }
>
> +static bool find_jump_target(const struct xt_table_info *t,
> + const void *entry0,
> + const struct ipt_entry *target)
> +{
> + struct ipt_entry *iter;
> +
> + xt_entry_foreach(iter, entry0, t->size) {
> + if (iter == target)
> + return true;
> + }
> + return false;
> +}
> +
> /* Figures out from what hook each rule can be called: returns 0 if
> there are loops. Puts hook bitmask in comefrom. */
> static int
> @@ -531,6 +544,10 @@ mark_source_chains(const struct xt_table_info *newinfo,
> /* This a jump; chase it. */
> duprintf("Jump rule %u -> %u\n",
>pos, newpos);
> + e = (struct ipt_entry *)
> + (entry0 + newpos);
> + if (!find_jump_target(newinfo, entry0,
> e))
> + return 0;
> } else {
> /* ... this is a fallthru */
> newpos = pos + e->next_offset;
> diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
> index 63f7876c4f29..97a8d2525c26 100644
> --- a/net/ipv6/netfilter/ip6_tables.c
> +++ b/net/ipv6/netfilter/ip6_tables.c
> @@ -444,6 +444,19 @@ ip6t_do_table(struct sk_buff *skb,
> #endif
> }
>
> +static bool find_jump_target(const struct xt_table_info *t,
> + const void *entry0,
> + const struct ip6t_entry *target)
> +{
> + struct ip6t_entry *iter;
> +
> + xt_entry_foreach(iter, entry0, t->size) {
> + if (iter == target)
> + return true;
> + }
> + return false;
> +}
> +
> /* Figures out from what hook each rule can be called: returns
Re: [PATCH 2/2] input: misc: Add support for Domintech DMARD06 accelerometer
On Thu, 21 Jul 2016 07:13:05 +0100
Jonathan Cameron wrote:
> On 20/07/16 01:02, Dmitry Torokhov wrote:
> > On Mon, Jul 18, 2016 at 03:48:12PM +0300, Aleksei Mamlin wrote:
> >> This patch add support for Domintech DMARD06 accelerometer.
> >>
> >> Domintech DMARD06 is a low-g tri-axial digital accelerometer with
> >> special power saving modes suitable for consumer mobile application.
> >
> > I'd say this belongs to IIO. The input/misc accelerometers are mostly
> > legacy.
> Also note we have a dmard09 driver under review on the IIO list
> at the moment. At quick glance, this looks to have a totally different
> register set though so probably doesn't make sense to combine the
> drivers.
>
I see dmard09 driver in linux-iio list and already prepare basic iio driver for
dmard06. I'll send it to linux-iio list today.
As you said, dmard06 and dmard09 use completely different registers.
>
> Do you have docs for this part? The dmard09 driver was written
> based on a vendor driver so little is known about what the other registers
> are for!
I have dmard05, dmard06 and dmard07 datasheets, but never seen dmard09.
Most of dmard06 registers used for interrupt source and events configuration,
power control and filtering.
>
> Jonathan
> >
> >>
> >> Signed-off-by: Aleksei Mamlin
> >> ---
> >> .../devicetree/bindings/input/dmard06.txt | 24 ++
> >> drivers/input/misc/Kconfig | 12 +
> >> drivers/input/misc/Makefile| 1 +
> >> drivers/input/misc/dmard06.c | 442
> >> +
> >> 4 files changed, 479 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/input/dmard06.txt
> >> create mode 100644 drivers/input/misc/dmard06.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/input/dmard06.txt
> >> b/Documentation/devicetree/bindings/input/dmard06.txt
> >> new file mode 100644
> >> index 000..528c318
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/input/dmard06.txt
> >> @@ -0,0 +1,24 @@
> >> +Device tree bindings for Domintech DMARD06 acceletometer
> >> +
> >> +Required properties:
> >> + - compatible : Should be "domintech,dmard06"
> >> + - reg: I2C address of the chip. Should be 0x1c
> >> +
> >> +Optional properties:
> >> + - interrupt-parent : Interrupt controller to which the chip is
> >> connected
> >> + - interrupts : Interrupt to which the chip is connected
> >> +
> >> +
> >> +Example:
> >> + &i2c1 {
> >> + /* ... */
> >> +
> >> + accelerometer@1c {
> >> + compatible = "domintech,dmard06";
> >> + reg = <0x1c>;
> >> + interrupt-parent = <&gpio>;
> >> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> >> + };
> >> +
> >> + /* ... */
> >> + };
> >> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> >> index efb0ca8..b95e0e7 100644
> >> --- a/drivers/input/misc/Kconfig
> >> +++ b/drivers/input/misc/Kconfig
> >> @@ -107,6 +107,18 @@ config INPUT_BMA150
> >> To compile this driver as a module, choose M here: the
> >> module will be called bma150.
> >>
> >> +config INPUT_DMARD06
> >> + tristate "Domintech DMARD06 Digital Accelerometer support"
> >> + depends on OF || COMPILE_TEST
> >> + depends on I2C
> >> + select INPUT_POLLDEV
> >> + help
> >> +Say Y to enable support for the Domintech DMARD06 Low-G Tri-Axial
> >> +digital accelerometer connected via an I2C bus.
> >> +
> >> +To compile this driver as a module, choose M here: the
> >> +module will be called dmard06.
> >> +
> >> config INPUT_E3X0_BUTTON
> >>tristate "NI Ettus Research USRP E3xx Button support."
> >>default n
> >> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> >> index 6a1e5e2..d83866f 100644
> >> --- a/drivers/input/misc/Makefile
> >> +++ b/drivers/input/misc/Makefile
> >> @@ -28,6 +28,7 @@ obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
> >> obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
> >> obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063_onkey.o
> >> obj-$(CONFIG_INPUT_DM355EVM) += dm355evm_keys.o
> >> +obj-$(CONFIG_INPUT_DMARD06) += dmard06.o
> >> obj-$(CONFIG_INPUT_E3X0_BUTTON) += e3x0-button.o
> >> obj-$(CONFIG_INPUT_DRV260X_HAPTICS) += drv260x.o
> >> obj-$(CONFIG_INPUT_DRV2665_HAPTICS) += drv2665.o
> >> diff --git a/drivers/input/misc/dmard06.c b/drivers/input/misc/dmard06.c
> >> new file mode 100644
> >> index 000..cc1e5a2
> >> --- /dev/null
> >> +++ b/drivers/input/misc/dmard06.c
> >> @@ -0,0 +1,442 @@
> >> +/*
> >> + * Driver for Domintech DMARD06 accelerometer
> >> + *
> >> + * Copyright (C) 2016 Aleksei Mamlin
> >> + * Copyright (c) 2012 Domintech Technology Co., Ltd
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms of the GNU General
Re: v4.1 to v4.7: regression in tsc2005 driver
Hi! > > In the mean time you can adjust the name or use XID instead. > > X has partially fixed this a few years ago. All input drivers (that > matter) export a Device Node property that sets the device node for each > device. > > $ xinput list-props "SynPS/2 Synaptics TouchPad" | grep "Device Node" > Device Node (261): "/dev/input/event4" > > Based on that you can get the udev device and work your way into any of the > sysfs tree. Or do whatever else you want. > > But other than that there isn't anything in X to fix. xinput is primarily a > debugging tool and it does name resolution for convenience. But it's not a > tool for complex configurations. It does exactly what it needs to do, if you > need something that's more complicated and relies on information not > available to the X device itself then you'll need to write a custom tool > that does what you need. sorry. Ok.. so out of the box, touchscreen is "upside down" and miscalibrated on n900. So I need to run xinput --set-prop --type=float 8 115 1.10 0.00 -0.05 0.00 1.18 -0.10 0.00 0.00 1.00 xinput --set-prop --type=int 8 249 0 1 (or equivalent with names) so that I can use the touchscreen. (And that's quite important -- X is somehow unusable without pointing device). If xinput is not the right solution, what is the right solution? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen
On Wed, Jul 20, 2016 at 10:29:10AM +0200, Quentin Schulz wrote: > This adds support for Allwinner SoCs' (A10, A13 and A31) resistive > touchscreen. This driver is probed by the MFD sunxi-gpadc-mfd. > > This driver uses ADC channels exposed through the IIO framework by > sunxi-gpadc-iio to get its data. When opening this input device, it will > start buffering in the ADC driver and enable a TP_UP_PENDING irq. The ADC > driver will fill in a buffer with all data and call the callback the input > device associated with this buffer. The input device will then read the > buffer two by two and send X and Y coordinates to the input framework based > on what it received from the ADC's buffer. When closing this input device, > the buffering is stopped. > > Note that locations in the first received buffer after an TP_UP_PENDING irq > occurred are unreliable, thus dropped. > > Signed-off-by: Quentin Schulz > --- > drivers/input/touchscreen/Kconfig | 11 +- > drivers/input/touchscreen/Makefile | 2 +- > drivers/input/touchscreen/sun4i-ts.c | 419 > - > drivers/input/touchscreen/sunxi-gpadc-ts.c | 195 ++ This new driver and the removal of the old one should be in two separate patches, the removal being in the last one. You break bisectability here, since the new driver won't be loaded, and the old one will not be there anymore. > 4 files changed, 201 insertions(+), 426 deletions(-) > delete mode 100644 drivers/input/touchscreen/sun4i-ts.c > create mode 100644 drivers/input/touchscreen/sunxi-gpadc-ts.c > > diff --git a/drivers/input/touchscreen/Kconfig > b/drivers/input/touchscreen/Kconfig > index 8ecdc38..f16ce36 100644 > --- a/drivers/input/touchscreen/Kconfig > +++ b/drivers/input/touchscreen/Kconfig > @@ -1072,14 +1072,13 @@ config TOUCHSCREEN_STMPE > config TOUCHSCREEN_SUN4I > tristate "Allwinner sun4i resistive touchscreen controller support" > depends on ARCH_SUNXI || COMPILE_TEST > - depends on HWMON > - depends on THERMAL || !THERMAL_OF > + depends on SUNXI_ADC > help > - This selects support for the resistive touchscreen controller > - found on Allwinner sunxi SoCs. > + This selects support for the resistive touchscreen controller found > + on Allwinner SoCs (A10, A13, A31). > > - To compile this driver as a module, choose M here: the > - module will be called sun4i-ts. > + To compile this driver as a module, choose M here: the module will be > + called sunxi-gpadc-ts. > > config TOUCHSCREEN_SUR40 > tristate "Samsung SUR40 (Surface 2.0/PixelSense) touchscreen" > diff --git a/drivers/input/touchscreen/Makefile > b/drivers/input/touchscreen/Makefile > index f42975e..bdc1889 100644 > --- a/drivers/input/touchscreen/Makefile > +++ b/drivers/input/touchscreen/Makefile > @@ -65,7 +65,7 @@ obj-$(CONFIG_TOUCHSCREEN_PIXCIR)+= pixcir_i2c_ts.o > obj-$(CONFIG_TOUCHSCREEN_S3C2410)+= s3c2410_ts.o > obj-$(CONFIG_TOUCHSCREEN_ST1232) += st1232.o > obj-$(CONFIG_TOUCHSCREEN_STMPE) += stmpe-ts.o > -obj-$(CONFIG_TOUCHSCREEN_SUN4I) += sun4i-ts.o > +obj-$(CONFIG_TOUCHSCREEN_SUN4I) += sunxi-gpadc-ts.o > obj-$(CONFIG_TOUCHSCREEN_SUR40) += sur40.o > obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o > obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o > diff --git a/drivers/input/touchscreen/sun4i-ts.c > b/drivers/input/touchscreen/sun4i-ts.c > deleted file mode 100644 > index d07dd29..000 > --- a/drivers/input/touchscreen/sun4i-ts.c > +++ /dev/null > @@ -1,419 +0,0 @@ > -/* > - * Allwinner sunxi resistive touchscreen controller driver > - * > - * Copyright (C) 2013 - 2014 Hans de Goede > - * > - * The hwmon parts are based on work by Corentin LABBE which is: > - * Copyright (C) 2013 Corentin LABBE > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - */ > - > -/* > - * The sun4i-ts controller is capable of detecting a second touch, but when a > - * second touch is present then the accuracy becomes so bad the reported > touch > - * location is not useable. > - * > - * The original android driver contains some complicated heuristics using the > - * aprox. distance between the 2 touches to see if the user is making a pinch > - * open / close movement, and then reports emulated multi-touch events around > - * the last touch coordinate (as the dual-touch coordinates are worthless). > - * > - * These kinds o
Re: [PATCH 5/9] staging: ks7010: Delete unnecessary uses of the variable "retval"
> >>> if (atomic_read(&priv->sleepstatus.status) == 0) {
> >>> rw_data = GCR_B_DOZE;
> >>> - retval =
> >>> - ks7010_sdio_write(priv, GCR_B, &rw_data, sizeof(rw_data));
> >>> - if (retval) {
> >>> + if (ks7010_sdio_write(priv,
> >>> + GCR_B,
> >>> + &rw_data,
> >>> + sizeof(rw_data))) {
> >>
> >> A multi-line function call in an if test does not look nice at all. The
> >> original code was an easy-to-read expectable pattern.
> >
> > I agree. I am not strict on the 80 char limit, especially in cases like
> > the above.
>
> Would you try an other source code formatting for the suggested change
> pattern?
I don't understand the question?
signature.asc
Description: PGP signature
Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api
On July 21, 2016 1:22:02 PM GMT+08:00, John Stultz wrote: >On Wed, Jul 20, 2016 at 9:26 PM, zhangfei >wrote: >> >> >> On 07/21/2016 11:53 AM, John Stultz wrote: >>> >>> After lots of debugging on an occasional DMA ERR issue, I realized >>> that the desc structures which we point the dma hardware are being >>> allocated out of regular memory. This means when we fill the desc >>> structures, that data doesn't always get flushed out to memory by >>> the time we start the dma transfer, resulting in the dma engine >getting >>> some null values, resulting in a DMA ERR on the first irq. >> >> >> How about using wmb() flush before start dma to sync desc? > >So I'm not going to pretend to be an expert here, but my understanding >is that wmb() syncrhonizes cpu write ordering operations across cpus, IIUI what the memory barrier does is tell the *compiler* to actually do any writes that the code asked for, but which otherwise might actually be deferred past that point. The compiler doesn't know that buffer area has other hardware snooping it, so by default it feels it can play tricks with what seems to it like just generally deferring spilling registers to memory. wmb makes sure the compiler's pending writes actually happen right there. (writel() etc definitions have one built-in, so they always do what you asked when you asked). That can be of interest when syncing with other cores but also to other IPs that intend to use the written-to area immediately, which is what's happening here. Without the barrier the write may not be issued anywhere, even to local cpu cache, until after the hw is asked to go read the buffer, corrupting what the hw sees. >so the cpus see all the changes before the wmb() before they see any >changes after. But I'm not sure what effect wmb() has across cpu >cache to device ordering. I don't think it works as a cache flush to >memory. > >Andy's patch introducing the cyclic support actually had a wmb() in it >that I removed as I couldn't understand clearly why it was there (and >there wasn't a comment explaining, as required by checkpatch :). But >even with that wmb(), the DMA ERR was still seen. The rule about the comment is there partially because there's a general tendancy for throwing voodoo smbs on broken things in case it helps. But writing out memory descriptors that other hw is going to read is a legit use for it I think. If the compiler you use wasn't deferring the write, you won't notice any difference removing it, but that doesn't mean it shouldn't be there. >Only with these two new changes have I gotten to the point where I >can't seem to trigger the DMA error. Sounds good... -Andy >thanks >-john
Re: staging: ks7010: Rename jump labels
Thank you very much for the heads up, Jean! signature.asc Description: PGP signature
Re: [PATCH 3/9] staging: ks7010: Return directly after a failed kmalloc()
On Wed, Jul 20, 2016 at 08:40:11PM +0200, SF Markus Elfring wrote:
> >>> @@ -713,10 +713,8 @@ static int ks7010_sdio_update_index(struct
> >>> ks_wlan_private *priv, u32 index)
> >>> unsigned char *data_buf;
> >>>
> >>> data_buf = kmalloc(sizeof(u32), GFP_KERNEL);
> >>> - if (!data_buf) {
> >>> - rc = 1;
> >>> - goto error_out;
> >>> - }
> >>> + if (!data_buf)
> >>> + return 1;
> >>
> >> One could rather wonder why the function has such strange error values...
> >
> > Agreed. Markus, can you check if we can use -ENOMEM in those places.
>
> I find that I do not know this software good enough at the moment
> so that I could safely decide on the shown special error values.
> I guess that further clarification might be needed for affected
> implementation details.
That's OK, too.
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
Re: [net-next PATCH 1/3] net: phy: dp83867: Add documentation for optional impedance control
Nishanth, On Wednesday 20 July 2016 09:03 PM, Nishanth Menon wrote: > On 07/20/2016 09:56 AM, Mugunthan V N wrote: >> Add documention of ti,impedance-control which can be used to >> correct MAC impedance mismatch using phy extended registers. >> >> Signed-off-by: Mugunthan V N >> --- >> Documentation/devicetree/bindings/net/ti,dp83867.txt | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt >> b/Documentation/devicetree/bindings/net/ti,dp83867.txt >> index 5d21141..531ea3c5 100644 >> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt >> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt >> @@ -9,6 +9,13 @@ Required properties: >> - ti,fifo-depth - Transmitt FIFO depth- see >> dt-bindings/net/ti-dp83867.h >> for applicable values >> >> +Optional property: >> +- ti,impedance-control - MAC Interface Impedance control to vary the >> + output impedance with an approximate range >> + from 35-70 ohms in 32 steps. Value range can >> + be 0x0 to 0x1f. Lowest impedance value is >> + 0x1f and highest impedance being 0x0. >> + > > Should'nt you be using the impedance values of 35 to 70 as the valid > values here? that would be the hardware description, and the values to > program corresponding to those are 0x00 to 0x1f. Right? > > Rob: is'nt that the right way to do it? Agree that that is usually the right way to do it. I believe this case is bit peculiar though. Here is the extract from the datasheet[1] about how the register in question works. " Output impedance approximate range from 35-70 ohms in 32 steps. Lowest being 0 and highest being 0. Range and Step size will vary with process. Default is set to 50 ohms by trim. But the default register value can vary by process. Non default values of MAC I/O impedance can be used based on trace impedance. Mismatch between device and trace impedance can cause voltage overshoot and undershoot. " So clearly, there is no easy correspondence that the hardware guarantees between output impedance ohmage and the register value programmed. Only couple of things are guaranteed. 1) Programming a value of 0 gives approximately 35 ohms 2) Programming a value of 0x1F gives approximately 70 ohms 3) Default value of the register gives 50 ohms (the default value could vary by device). 4) Programming a value in between will give some ohmage in the approximate range 35-70 (curve is unknown). Given this, I am not sure how one can convert a given user supplied ohms values to a reasonable register value. Clearly, the register is supposed to be programmed by experimentation, not calculation. That said, we could take another approach. At least for the current issue we are trying to address, we only need to configure the register to max value. And given the nature of the register, I am pretty sure that is what most people will end up doing. So, may be we have two properties: ti,max-output-impedance ti,min-output-imepdance which configure the impedance to maximum and minimum values respectively. If, in future, someone needs to configure a value in between, he can introduce a more granular property which when then override whatever else is specified. Regards, Sekhar [1] http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[PATCH] fs: uninline build_open_flags()
Saves ~450 bytes with my usual config.
$ size vmlinux-000 vmlinux
textdata bss dec hex filename
6752803 3325000 708608 10786411 a4966b vmlinux-000
6752355 3325000 708608 10785963 a494ab vmlinux
Signed-off-by: Alexey Dobriyan
---
fs/open.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/open.c
+++ b/fs/open.c
@@ -880,7 +880,7 @@ struct file *dentry_open(const struct path *path, int flags,
}
EXPORT_SYMBOL(dentry_open);
-static inline int build_open_flags(int flags, umode_t mode, struct open_flags
*op)
+static int build_open_flags(int flags, umode_t mode, struct open_flags *op)
{
int lookup_flags = 0;
int acc_mode = ACC_MODE(flags);
Re: [PATCH 02/10] mfd: cros_ec: update MOTIONSENSE definitions and commands.
On 19/07/16 19:00, Enric Balletbo Serra wrote:
> Hi Jonathan,
>
> Many thanks for your comments.
>
> 2016-07-18 15:49 GMT+02:00 Jonathan Cameron :
>> On 18/07/16 08:02, Enric Balletbo i Serra wrote:
>>> Let's update the command header to include the definitions related to
>>> the sensors attached behind the ChromeOS Embedded Controller. The new
>>> commands and definitions allow us to get information from these sensors.
>>>
>>> Signed-off-by: Gwendal Grignou
>>> Signed-off-by: Enric Balletbo i Serra
>> Again, I'd be happier seeing this stuff introduced as and when it
>> is needed rather than in a magic patch. It's hard to review stuff
>> if it's broken up across multiple patches like this.
>>
>> A few other bits and pieces inline.
>>
>> Jonathan
>>> ---
>>> include/linux/mfd/cros_ec_commands.h | 260
>>> +++
>>> 1 file changed, 231 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/include/linux/mfd/cros_ec_commands.h
>>> b/include/linux/mfd/cros_ec_commands.h
>>> index 76728ff..f26a806 100644
>>> --- a/include/linux/mfd/cros_ec_commands.h
>>> +++ b/include/linux/mfd/cros_ec_commands.h
>>> @@ -1290,7 +1290,13 @@ enum motionsense_command {
>>>
>>> /*
>>>* EC Rate command is a setter/getter command for the EC sampling rate
>>> - * of all motion sensors in milliseconds.
>>> + * in milliseconds.
>>> + * It is per sensor, the EC run sample task at the minimum of all
>>> + * sensors EC_RATE.
>>> + * For sensors without hardware FIFO, EC_RATE should be equals to
>>> 1/ODR
>>> + * to collect all the sensor samples.
>>> + * For sensor with hardware FIFO, EC_RATE is used as the maximal delay
>>> + * to process of all motion sensors in milliseconds.
>>>*/
>>> MOTIONSENSE_CMD_EC_RATE = 2,
>>>
>>> @@ -1315,37 +1321,138 @@ enum motionsense_command {
>>>*/
>>> MOTIONSENSE_CMD_KB_WAKE_ANGLE = 5,
>>>
>>> - /* Number of motionsense sub-commands. */
>>> - MOTIONSENSE_NUM_CMDS
>>> -};
>>> + /*
>>> + * Returns a single sensor data.
>>> + */
>> Please use standard kernel documentation formats throughout.
>> If not you may face a Linus rant ;)
>
> Seems that this specific file does not follow the kernel-doc format
> strictly [1], should I add the new entries in kernel-doc format or
> follow the file style?
>
> Or maybe I should first do a patch to change all the file to the
> kernel-doc format?
It would be a nice tidy up to fix the file. Good to get any
new comments in the right style though - fixing old ones can
happen any time.
>
> Or you meant only replace the
>
> /*
> * one line
> */
>
> for
>
> /* one line */
Definitely do that one.
>
> [1] https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt
>
>>> + MOTIONSENSE_CMD_DATA = 6,
>>> +
>>> + /*
>>> + * Return sensor fifo info.
>>> + */
>>> + MOTIONSENSE_CMD_FIFO_INFO = 7,
>>> +
>>> + /*
>>> + * Insert a flush element in the fifo and return sensor fifo info.
>>> + * The host can use that element to synchronize its operation.
>>> + */
>>> + MOTIONSENSE_CMD_FIFO_FLUSH = 8,
>>>
>>> -enum motionsensor_id {
>>> - EC_MOTION_SENSOR_ACCEL_BASE = 0,
>>> - EC_MOTION_SENSOR_ACCEL_LID = 1,
>>> - EC_MOTION_SENSOR_GYRO = 2,
>>> + /*
>>> + * Return a portion of the fifo.
>>> + */
>>> + MOTIONSENSE_CMD_FIFO_READ = 9,
>>> +
>>> + /*
>>> + * Perform low level calibration.
>>> + * On sensors that support it, ask to do offset calibration.
>>> + */
>>> + MOTIONSENSE_CMD_PERFORM_CALIB = 10,
>>> +
>>> + /*
>>> + * Sensor Offset command is a setter/getter command for the offset
>>> + * used for calibration.
>>> + * The offsets can be calculated by the host, or via
>>> + * PERFORM_CALIB command.
>>> + */
>>> + MOTIONSENSE_CMD_SENSOR_OFFSET = 11,
>>> +
>>> + /*
>>> + * List available activities for a MOTION sensor.
>>> + * Indicates if they are enabled or disabled.
>>> + */
>>> + MOTIONSENSE_CMD_LIST_ACTIVITIES = 12,
>>>
>>> /*
>>> - * Note, if more sensors are added and this count changes, the padding
>>> - * in ec_response_motion_sense dump command must be modified.
>>> + * Activity management
>>> + * Enable/Disable activity recognition.
>>>*/
>>> - EC_MOTION_SENSOR_COUNT = 3
>>> + MOTIONSENSE_CMD_SET_ACTIVITY = 13,
>>> +
>>> + /* Number of motionsense sub-commands. */
>>> + MOTIONSENSE_NUM_CMDS
>>> };
>>>
>>> /* List of motion sensor types. */
>>> enum motionsensor_type {
>>> MOTIONSENSE_TYPE_ACCEL = 0,
>>> MOTIONSENSE_TYPE_GYRO = 1,
>>> + MOTIONSENSE_TYPE_MAG = 2,
>>> + MOTIONSENSE_TYPE_PROX = 3,
>>> + MOTIONSENSE_TYPE_LIGHT = 4,
>>> + MOTIONSENSE_TYPE_ACTIVITY = 5,
>>> + MOTIONSENSE_TYPE_MAX,
>>> };
>>>
>>> /* List of motion sensor locations. */
>>> enum motionsensor_location {
>>> MOTIO
linux-next: build failure after merge of the nvdimm tree
Hi Dan,
After merging the nvdimm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/sysdev/axonram.c: In function 'axon_ram_direct_access':
arch/powerpc/sysdev/axonram.c:151:9: error: assignment makes pointer from
integer without a cast [-Werror=int-conversion]
*kaddr = bank->io_addr + offset;
^
Caused by commit
6e9c9dda79d9 ("pmem: kill __pmem address space")
I have used the nvdimm tree from next-20160720 for today.
--
Cheers,
Stephen Rothwell
Re: [PATCH 2/2] input: misc: Add support for Domintech DMARD06 accelerometer
On 20/07/16 01:02, Dmitry Torokhov wrote:
> On Mon, Jul 18, 2016 at 03:48:12PM +0300, Aleksei Mamlin wrote:
>> This patch add support for Domintech DMARD06 accelerometer.
>>
>> Domintech DMARD06 is a low-g tri-axial digital accelerometer with
>> special power saving modes suitable for consumer mobile application.
>
> I'd say this belongs to IIO. The input/misc accelerometers are mostly
> legacy.
Also note we have a dmard09 driver under review on the IIO list
at the moment. At quick glance, this looks to have a totally different
register set though so probably doesn't make sense to combine the
drivers.
Do you have docs for this part? The dmard09 driver was written
based on a vendor driver so little is known about what the other registers
are for!
Jonathan
>
>>
>> Signed-off-by: Aleksei Mamlin
>> ---
>> .../devicetree/bindings/input/dmard06.txt | 24 ++
>> drivers/input/misc/Kconfig | 12 +
>> drivers/input/misc/Makefile| 1 +
>> drivers/input/misc/dmard06.c | 442
>> +
>> 4 files changed, 479 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/input/dmard06.txt
>> create mode 100644 drivers/input/misc/dmard06.c
>>
>> diff --git a/Documentation/devicetree/bindings/input/dmard06.txt
>> b/Documentation/devicetree/bindings/input/dmard06.txt
>> new file mode 100644
>> index 000..528c318
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/dmard06.txt
>> @@ -0,0 +1,24 @@
>> +Device tree bindings for Domintech DMARD06 acceletometer
>> +
>> +Required properties:
>> + - compatible : Should be "domintech,dmard06"
>> + - reg : I2C address of the chip. Should be 0x1c
>> +
>> +Optional properties:
>> + - interrupt-parent : Interrupt controller to which the chip is connected
>> + - interrupts : Interrupt to which the chip is connected
>> +
>> +
>> +Example:
>> +&i2c1 {
>> +/* ... */
>> +
>> +accelerometer@1c {
>> +compatible = "domintech,dmard06";
>> +reg = <0x1c>;
>> +interrupt-parent = <&gpio>;
>> +interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> +};
>> +
>> +/* ... */
>> +};
>> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
>> index efb0ca8..b95e0e7 100644
>> --- a/drivers/input/misc/Kconfig
>> +++ b/drivers/input/misc/Kconfig
>> @@ -107,6 +107,18 @@ config INPUT_BMA150
>>To compile this driver as a module, choose M here: the
>>module will be called bma150.
>>
>> +config INPUT_DMARD06
>> +tristate "Domintech DMARD06 Digital Accelerometer support"
>> +depends on OF || COMPILE_TEST
>> +depends on I2C
>> +select INPUT_POLLDEV
>> +help
>> + Say Y to enable support for the Domintech DMARD06 Low-G Tri-Axial
>> + digital accelerometer connected via an I2C bus.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called dmard06.
>> +
>> config INPUT_E3X0_BUTTON
>> tristate "NI Ettus Research USRP E3xx Button support."
>> default n
>> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
>> index 6a1e5e2..d83866f 100644
>> --- a/drivers/input/misc/Makefile
>> +++ b/drivers/input/misc/Makefile
>> @@ -28,6 +28,7 @@ obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
>> obj-$(CONFIG_INPUT_DA9055_ONKEY)+= da9055_onkey.o
>> obj-$(CONFIG_INPUT_DA9063_ONKEY)+= da9063_onkey.o
>> obj-$(CONFIG_INPUT_DM355EVM)+= dm355evm_keys.o
>> +obj-$(CONFIG_INPUT_DMARD06) += dmard06.o
>> obj-$(CONFIG_INPUT_E3X0_BUTTON) += e3x0-button.o
>> obj-$(CONFIG_INPUT_DRV260X_HAPTICS) += drv260x.o
>> obj-$(CONFIG_INPUT_DRV2665_HAPTICS) += drv2665.o
>> diff --git a/drivers/input/misc/dmard06.c b/drivers/input/misc/dmard06.c
>> new file mode 100644
>> index 000..cc1e5a2
>> --- /dev/null
>> +++ b/drivers/input/misc/dmard06.c
>> @@ -0,0 +1,442 @@
>> +/*
>> + * Driver for Domintech DMARD06 accelerometer
>> + *
>> + * Copyright (C) 2016 Aleksei Mamlin
>> + * Copyright (c) 2012 Domintech Technology Co., Ltd
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> Free
>> + * Software Foundation; version 2 of the License.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/* Device data registers */
>> +#define DMARD06_CHIP_ID_REG 0x0f
>> +#define DMARD06_TOUT_REG0x40
>> +#define DMARD06_XOUT_REG0x41
>> +#define DMARD06_YOUT_REG0x42
>> +#define DMARD06_ZOUT_REG0x43
>> +
>> +/* Device control registers */
>> +#define DMARD06_CTRL_1_REG 0x44
>> +#define DMARD06_CTRL_2_REG
Re: [PATCH 5/5] mfd: sunxi-gpadc-mfd: probe sunxi-gpadc-ts driver
Hi Quentin,
On Wed, Jul 20, 2016 at 10:29:11AM +0200, Quentin Schulz wrote:
> This probes the touchscreen driver for Allwinner SoCs (A10, A13 and A31)
> when the property "allwinner,ts-attached" is set in the GPADC (rtp) node of
> the DT.
>
> Some comestic modifications done to shorten and increase readability of the
> code.
>
> Signed-off-by: Quentin Schulz
> ---
> drivers/mfd/sunxi-gpadc-mfd.c | 115
> --
> 1 file changed, 77 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/mfd/sunxi-gpadc-mfd.c b/drivers/mfd/sunxi-gpadc-mfd.c
> index 05a000b..9b9ed0b 100644
> --- a/drivers/mfd/sunxi-gpadc-mfd.c
> +++ b/drivers/mfd/sunxi-gpadc-mfd.c
> @@ -21,6 +21,11 @@
> #define SUNXI_IRQ_TEMP_DATA 1
> #define SUNXI_IRQ_TP_UP 2
>
> +#define SUNXI_GPADC_MFD_CELL(_name, _resources, _num_resources) {\
> + .name = _name, \
> + .resources = _resources,\
> + .num_resources = _num_resources \
> +}
>
> static struct resource adc_resources[] = {
> {
> @@ -64,33 +69,45 @@ static const struct regmap_irq_chip
> sunxi_gpadc_mfd_regmap_irq_chip = {
> };
>
> static struct mfd_cell sun4i_gpadc_mfd_cells[] = {
> - {
> - .name = "sun4i-a10-gpadc-iio",
> - .resources = adc_resources,
> - .num_resources = ARRAY_SIZE(adc_resources),
> - }, {
> - .name = "iio_hwmon",
> - }
> + SUNXI_GPADC_MFD_CELL("sun4i-a10-gpadc-iio", adc_resources,
> + ARRAY_SIZE(adc_resources)),
> + SUNXI_GPADC_MFD_CELL("iio_hwmon", NULL, 0),
> };
>
> static struct mfd_cell sun5i_gpadc_mfd_cells[] = {
> - {
> - .name = "sun5i-a13-gpadc-iio",
> - .resources = adc_resources,
> - .num_resources = ARRAY_SIZE(adc_resources),
> - }, {
> - .name = "iio_hwmon",
> - },
> + SUNXI_GPADC_MFD_CELL("sun5i-a13-gpadc-iio", adc_resources,
> + ARRAY_SIZE(adc_resources)),
> + SUNXI_GPADC_MFD_CELL("iio_hwmon", NULL, 0),
> };
>
> static struct mfd_cell sun6i_gpadc_mfd_cells[] = {
> - {
> - .name = "sun6i-a31-gpadc-iio",
> - .resources = adc_resources,
> - .num_resources = ARRAY_SIZE(adc_resources),
> - }, {
> - .name = "iio_hwmon",
> - },
> + SUNXI_GPADC_MFD_CELL("sun6i-a31-gpadc-iio", adc_resources,
> + ARRAY_SIZE(adc_resources)),
> + SUNXI_GPADC_MFD_CELL("iio_hwmon", NULL, 0),
> +};
This should be part of a separate patch.
> +
> +static struct mfd_cell sun4i_gpadc_mfd_cells_ts[] = {
> + SUNXI_GPADC_MFD_CELL("sun6i-a31-gpadc-iio", adc_resources,
> + ARRAY_SIZE(adc_resources)),
> + SUNXI_GPADC_MFD_CELL("iio_hwmon", NULL, 0),
> + SUNXI_GPADC_MFD_CELL("sunxi-gpadc-ts", ts_resources,
> + ARRAY_SIZE(ts_resources)),
> +};
> +
> +static struct mfd_cell sun5i_gpadc_mfd_cells_ts[] = {
> + SUNXI_GPADC_MFD_CELL("sun5i-a13-gpadc-iio", adc_resources,
> + ARRAY_SIZE(adc_resources)),
> + SUNXI_GPADC_MFD_CELL("iio_hwmon", NULL, 0),
> + SUNXI_GPADC_MFD_CELL("sunxi-gpadc-ts", ts_resources,
> + ARRAY_SIZE(ts_resources)),
> +};
> +
> +static struct mfd_cell sun6i_gpadc_mfd_cells_ts[] = {
> + SUNXI_GPADC_MFD_CELL("sun6i-a31-gpadc-iio", adc_resources,
> + ARRAY_SIZE(adc_resources)),
> + SUNXI_GPADC_MFD_CELL("iio_hwmon", NULL, 0),
> + SUNXI_GPADC_MFD_CELL("sunxi-gpadc-ts", ts_resources,
> + ARRAY_SIZE(ts_resources)),
> };
>
> static const struct regmap_config sunxi_gpadc_mfd_regmap_config = {
> @@ -142,23 +159,45 @@ static int sunxi_gpadc_mfd_probe(struct platform_device
> *pdev)
> }
>
> if (of_device_is_compatible(pdev->dev.of_node,
> - "allwinner,sun4i-a10-ts"))
> - ret = mfd_add_devices(sunxi_gpadc_mfd_dev->dev, 0,
> - sun4i_gpadc_mfd_cells,
> - ARRAY_SIZE(sun4i_gpadc_mfd_cells), NULL,
> - 0, NULL);
> - else if (of_device_is_compatible(pdev->dev.of_node,
> - "allwinner,sun5i-a13-ts"))
> - ret = mfd_add_devices(sunxi_gpadc_mfd_dev->dev, 0,
> - sun5i_gpadc_mfd_cells,
> - ARRAY_SIZE(sun5i_gpadc_mfd_cells), NULL,
> - 0, NULL);
> - else if (of_device_is_compatible(pdev->dev.of_node,
> - "allwinner,sun6i-a31-ts"))
> - ret = mfd_add_devices(sunxi_gpadc_mfd_dev->dev, 0,
> - sun6i_gpadc_mfd_cells,
> -
Re: [PATCH v3 00/15] net: thunderx: Add support for 81xx and 83xx
A gentle reminder to consider the patchset for either review or acceptance. Thanks, Sunil.
Re: [RFC][PATCH 2/2 v3] security: Add task_settimerslack/task_gettimerslack LSM hook
On Tue, Jul 19, 2016 at 11:12 PM, James Morris wrote: > On Mon, 18 Jul 2016, John Stultz wrote: > >> As requested, this patch implements a task_settimerslack and >> task_gettimerslack LSM hooks so that the /proc//timerslack_ns >> interface can have finer grained security policies applied to it. >> >> I've kept the CAP_SYS_NICE check in the timerslack_ns_write/show >> functions, as hiding it in the LSM hook seems too opaque, and doesn't >> seem like a widely enough adopted practice. >> > > I may have missed something in the earlier discussion, but why do we need > new LSM hooks here vs. calling the existing set/getscheduler hooks? Mostly since adding a new hook was suggested originally. I don't think there's much difference as it stands, but I guess more fine grained checks could be added on the slack amounts, etc. I can rework it, so let me know if using the existing hooks would be preferred, but otherwise I'll be sending out the non-rfc patches tomorrow. thanks -john
Re: [PATCH 5/5] mm: consider per-zone inactive ratio to deactivate
Hi Mel, On Wed, Jul 20, 2016 at 04:21:51PM +0100, Mel Gorman wrote: > From: Minchan Kim > > Minchan Kim reported that with per-zone lru state it was possible to > identify that a normal zone with 8^M anonymous pages could trigger > OOM with non-atomic order-0 allocations as all pages in the zone > were in the active list. > >gfp_mask=0x26004c0(GFP_KERNEL|__GFP_REPEAT|__GFP_NOTRACK), order=0 >Call Trace: > [] __alloc_pages_nodemask+0xe52/0xe60 > [] ? new_slab+0x39c/0x3b0 > [] new_slab+0x39c/0x3b0 > [] ___slab_alloc.constprop.87+0x6da/0x840 > [] ? __alloc_skb+0x3c/0x260 > [] ? enqueue_task_fair+0x73/0xbf0 > [] ? poll_select_copy_remaining+0x140/0x140 > [] __slab_alloc.isra.81.constprop.86+0x40/0x6d > [] ? __alloc_skb+0x3c/0x260 > [] kmem_cache_alloc+0x22c/0x260 > [] ? __alloc_skb+0x3c/0x260 > [] __alloc_skb+0x3c/0x260 > [] alloc_skb_with_frags+0x4e/0x1a0 > [] sock_alloc_send_pskb+0x16a/0x1b0 > [] ? wait_for_unix_gc+0x31/0x90 > [] unix_stream_sendmsg+0x28d/0x340 > [] sock_sendmsg+0x2d/0x40 > [] sock_write_iter+0x6c/0xc0 > [] __vfs_write+0xc0/0x120 > [] vfs_write+0x9b/0x1a0 > [] ? __might_fault+0x49/0xa0 > [] SyS_write+0x44/0x90 > [] do_fast_syscall_32+0xa6/0x1e0 > >Mem-Info: >active_anon:101103 inactive_anon:102219 isolated_anon:0 > active_file:503 inactive_file:544 isolated_file:0 > unevictable:0 dirty:0 writeback:34 unstable:0 > slab_reclaimable:6298 slab_unreclaimable:74669 > mapped:863 shmem:0 pagetables:100998 bounce:0 > free:23573 free_pcp:1861 free_cma:0 >Node 0 active_anon:404412kB inactive_anon:409040kB active_file:2012kB > inactive_file:2176kB unevictable:0kB isolated(anon):0kB isolated(file):0kB > mapped:3452kB dirty:0kB writeback:136kB shmem:0kB writeback_tmp:0kB > unstable:0kB pages_scanned:1320845 all_unreclaimable? yes >DMA free:3296kB min:68kB low:84kB high:100kB active_anon:5540kB > inactive_anon:0kB active_file:0kB inactive_file:0kB present:15992kB > managed:15916kB mlocked:0kB slab_reclaimable:248kB slab_unreclaimable:2628kB > kernel_stack:792kB pagetables:2316kB bounce:0kB free_pcp:0kB local_pcp:0kB > free_cma:0kB >lowmem_reserve[]: 0 809 1965 1965 >Normal free:3600kB min:3604kB low:4504kB high:5404kB active_anon:86304kB > inactive_anon:0kB active_file:160kB inactive_file:376kB present:897016kB > managed:858524kB mlocked:0kB slab_reclaimable:24944kB > slab_unreclaimable:296048kB kernel_stack:163832kB pagetables:35892kB > bounce:0kB free_pcp:3076kB local_pcp:656kB free_cma:0kB >lowmem_reserve[]: 0 0 9247 9247 >HighMem free:86156kB min:512kB low:1796kB high:3080kB active_anon:312852kB > inactive_anon:410024kB active_file:1924kB inactive_file:2012kB > present:1183736kB managed:1183736kB mlocked:0kB slab_reclaimable:0kB > slab_unreclaimable:0kB kernel_stack:0kB pagetables:365784kB bounce:0kB > free_pcp:3868kB local_pcp:720kB free_cma:0kB >lowmem_reserve[]: 0 0 0 0 >DMA: 8*4kB (UM) 8*8kB (UM) 4*16kB (M) 2*32kB (UM) 2*64kB (UM) 1*128kB (M) > 3*256kB (UME) 2*512kB (UE) 1*1024kB (E) 0*2048kB 0*4096kB = 3296kB >Normal: 240*4kB (UME) 160*8kB (UME) 23*16kB (ME) 3*32kB (UE) 3*64kB (UME) > 2*128kB (ME) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3408kB >HighMem: 10942*4kB (UM) 3102*8kB (UM) 866*16kB (UM) 76*32kB (UM) 11*64kB > (UM) 4*128kB (UM) 1*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 86344kB >Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 > hugepages_size=2048kB >54409 total pagecache pages >53215 pages in swap cache >Swap cache stats: add 300982, delete 247765, find 157978/226539 >Free swap = 3803244kB >Total swap = 4192252kB >524186 pages RAM >295934 pages HighMem/MovableOnly >9642 pages reserved >0 pages cma reserved > > The problem is due to the active deactivation logic in inactive_list_is_low. > > Node 0 active_anon:404412kB inactive_anon:409040kB > > IOW, (inactive_anon of node * inactive_ratio > active_anon of node) due to > highmem anonymous stat so VM never deactivates normal zone's anonymous pages. > > This patch is a modified version of Minchan's original solution but based > upon it. The problem with Minchan's patch is that it didn't take memcg > into account and any low zone with an imbalanced list could force a rotation. Could you explan why we should consider memcg here? > > In this page, a zone-constrained global reclaim will rotate the list if patch, > the inactive/active ratio of all eligible zones needs to be corrected. It > is possible that higher zone pages will be initially rotated prematurely > but this is the safer choice to maintain overall LRU age. > > Signed-off-by: Minchan Kim > Signed-off-by: Mel Gorman > --- > mm/vmscan.c | 37 - > 1 file changed, 32 insertions(+), 5 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 8f5959469079..dddf73f42
linux-next: build warnings after merge of the libata tree
Hi Tejun,
After merging the libata tree, today's linux-next build (arm
multi_v7_defconfig) produced these warning:
drivers/ata/libata-scsi.c: In function 'ata_mselect_caching':
drivers/ata/libata-scsi.c:3637:28: warning: suggest parentheses around
comparison in operand of '&' [-Wparentheses]
if (mpage[i + 2] & 0xfb != buf[i] & 0xfb) {
^
drivers/ata/libata-scsi.c: In function 'ata_mselect_control':
drivers/ata/libata-scsi.c:3702:28: warning: suggest parentheses around
comparison in operand of '&' [-Wparentheses]
if (mpage[i + 2] & 0xfb != buf[i] & 0xfb) {
^
Introduced by commit
9b7844a8c34a ("libata-scsi: fix read-only bits checking in ata_mselect_*()")
--
Cheers,
Stephen Rothwell
[PATCH v2 0/2] Fix issue with alternatives/paravirt patches
Hi,
A few months ago, Chris Arges reported a bug involving alternatives/paravirt
patching that was discussed here [1] and here [2]. To briefly summarize the
bug, patch modules that contained .altinstructions or .parainstructions
sections would break because these alternative/paravirt patches would be
applied first by the module loader (see x86 module_finalize()), then
livepatch would later clobber these patches when applying per-object
relocations. This lead to crashes and unpredictable behavior.
One conclusion we reached from our last discussion was that we will
need to introduce some arch-specific code to address this problem.
This patchset presents a possible fix for the bug by adding a new
arch-specific arch_klp_init_object_loaded() function that by default
does nothing but can be overridden by different arches.
To fix this issue for x86, since we can access a patch module's Elf
sections through mod->klp_info, we can simply delay the calls to
apply_paravirt() and apply_alternatives() to arch_klp_init_object_loaded(),
which is called after relocations have been written for an object.
In addition, for patch modules, .parainstructions and .altinstructions are
prefixed by ".klp.arch.${objname}" so that the module loader ignores them
and livepatch can apply them manually.
Currently for kpatch, we don't support including jump table sections in
the patch module, and supporting .smp_locks is currently broken, so we
don't consider those sections (for now).
I did some light testing with some patches to kvm and verified that the
original issue reported in [2] was fixed.
Based on linux-next.
v1 here:
http://lkml.kernel.org/g/1467772500-26092-1-git-send-email-j...@redhat.com
v2:
- add BUILD_BUG_ON() check in arch_klp_init_object_loaded (x86)
[1] http://thread.gmane.org/gmane.linux.kernel/2185604/
[2] https://github.com/dynup/kpatch/issues/580
Jessica Yu (2):
livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks
livepatch/x86: apply alternatives and paravirt patches after relocations
arch/x86/kernel/Makefile| 1 +
arch/x86/kernel/livepatch.c | 65 +
include/linux/livepatch.h | 3 +++
kernel/livepatch/core.c | 12 +++--
4 files changed, 79 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/kernel/livepatch.c
--
2.5.5
[PATCH v2 1/2] livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks
Introduce arch_klp_init_object_loaded() to complete any additional
arch-specific tasks during patching. Architecture code may override this
function.
Signed-off-by: Jessica Yu
---
include/linux/livepatch.h | 3 +++
kernel/livepatch/core.c | 12 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index a93a0b2..9072f04 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -116,6 +116,9 @@ int klp_unregister_patch(struct klp_patch *);
int klp_enable_patch(struct klp_patch *);
int klp_disable_patch(struct klp_patch *);
+void arch_klp_init_object_loaded(struct klp_patch *patch,
+struct klp_object *obj);
+
/* Called from the module loader during module coming/going states */
int klp_module_coming(struct module *mod);
void klp_module_going(struct module *mod);
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 5c2bc10..164eff6 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -274,7 +274,6 @@ static int klp_write_object_relocations(struct module *pmod,
objname = klp_is_module(obj) ? obj->name : "vmlinux";
- module_disable_ro(pmod);
/* For each klp relocation section */
for (i = 1; i < pmod->klp_info->hdr.e_shnum; i++) {
sec = pmod->klp_info->sechdrs + i;
@@ -309,7 +308,6 @@ static int klp_write_object_relocations(struct module *pmod,
break;
}
- module_enable_ro(pmod);
return ret;
}
@@ -763,6 +761,12 @@ static int klp_init_func(struct klp_object *obj, struct
klp_func *func)
func->old_sympos ? func->old_sympos : 1);
}
+/* Arches may override this to finish any remaining arch-specific tasks */
+void __weak arch_klp_init_object_loaded(struct klp_patch *patch,
+ struct klp_object *obj)
+{
+}
+
/* parts of the initialization that is done only when the object is loaded */
static int klp_init_object_loaded(struct klp_patch *patch,
struct klp_object *obj)
@@ -770,10 +774,14 @@ static int klp_init_object_loaded(struct klp_patch *patch,
struct klp_func *func;
int ret;
+ module_disable_ro(patch->mod);
ret = klp_write_object_relocations(patch->mod, obj);
if (ret)
return ret;
+ arch_klp_init_object_loaded(patch, obj);
+ module_enable_ro(patch->mod);
+
klp_for_each_func(obj, func) {
ret = klp_find_object_symbol(obj->name, func->old_name,
func->old_sympos,
--
2.5.5
[PATCH v2 2/2] livepatch/x86: apply alternatives and paravirt patches after relocations
Implement arch_klp_init_object_loaded() for x86, which applies
alternatives/paravirt patches. This fixes the order in which relocations
and alternatives/paravirt patches are applied.
Previously, if a patch module had alternatives or paravirt patches,
these were applied first by the module loader before livepatch can apply
per-object relocations. The (buggy) sequence of events was:
(1) Load patch module
(2) Apply alternatives and paravirt patches to patch module
* Note that these are applied to the new functions in the patch module
(3) Apply per-object relocations to patch module when target module loads.
* This clobbers what was written in step 2
This lead to crashes and corruption in general, since livepatch would
overwrite or step on previously applied alternative/paravirt patches.
The correct sequence of events should be:
(1) Load patch module
(2) Apply per-object relocations to patch module
(3) Apply alternatives and paravirt patches to patch module
This is fixed by delaying paravirt/alternatives patching until after
relocations are applied. Any .altinstructions or .parainstructions sections in
a patch module are prefixed with ".klp.arch.${objname}" and applied in
arch_klp_init_object_loaded().
Signed-off-by: Jessica Yu
---
arch/x86/kernel/Makefile| 1 +
arch/x86/kernel/livepatch.c | 65 +
2 files changed, 66 insertions(+)
create mode 100644 arch/x86/kernel/livepatch.c
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0503f5b..4f656fe 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-y += apic/
obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
+obj-$(CONFIG_LIVEPATCH)+= livepatch.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace.o
obj-$(CONFIG_X86_TSC) += trace_clock.o
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
new file mode 100644
index 000..78209f1
--- /dev/null
+++ b/arch/x86/kernel/livepatch.c
@@ -0,0 +1,65 @@
+/*
+ * livepatch.c - x86-specific Kernel Live Patching Core
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api
On Wed, Jul 20, 2016 at 9:26 PM, zhangfei wrote: > > > On 07/21/2016 11:53 AM, John Stultz wrote: >> >> After lots of debugging on an occasional DMA ERR issue, I realized >> that the desc structures which we point the dma hardware are being >> allocated out of regular memory. This means when we fill the desc >> structures, that data doesn't always get flushed out to memory by >> the time we start the dma transfer, resulting in the dma engine getting >> some null values, resulting in a DMA ERR on the first irq. > > > How about using wmb() flush before start dma to sync desc? So I'm not going to pretend to be an expert here, but my understanding is that wmb() syncrhonizes cpu write ordering operations across cpus, so the cpus see all the changes before the wmb() before they see any changes after. But I'm not sure what effect wmb() has across cpu cache to device ordering. I don't think it works as a cache flush to memory. Andy's patch introducing the cyclic support actually had a wmb() in it that I removed as I couldn't understand clearly why it was there (and there wasn't a comment explaining, as required by checkpatch :). But even with that wmb(), the DMA ERR was still seen. Only with these two new changes have I gotten to the point where I can't seem to trigger the DMA error. thanks -john
[PATCH/V2] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9
Boot the system without this entry generates following warning.
fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver
After apply this patch, no more conflict message.
fb: switching to mgag200drmfb from EFI VGA
Compile and tested on DL360 Gen9 and it works both console and X.
Signed-off-by: Masanari Iida
Suggested-by: Shane Seymour
---
include/drm/drm_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 8bc073d297db..3e16dfc2e08d 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -743,6 +743,7 @@
#define mga_PCI_IDS \
{0x102b, 0x0520, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
{0x102b, 0x0521, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
+ {0x102b, 0x0533, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
{0x102b, 0x0525, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G400}, \
{0x102b, 0x2527, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G550}, \
{0, 0, 0}
--
2.9.2.368.g08bb350
Re: [PATCH] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9
I made mistake to type shane's e-mail address, so I will send version
2. Sorry for the noise.
Masanari
On Thu, Jul 21, 2016 at 2:12 PM, Masanari Iida wrote:
> Boot the system without this entry generates following warning.
> fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver
>
> After apply this patch, no more conflict message.
> fb: switching to mgag200drmfb from EFI VGA
>
> Compile and tested on DL360 Gen9 and it works both console and X.
>
> Signed-off-by: Masanari Iida
> Suggested-by: Shane Seymour
> ---
> include/drm/drm_pciids.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
> index 8bc073d297db..3e16dfc2e08d 100644
> --- a/include/drm/drm_pciids.h
> +++ b/include/drm/drm_pciids.h
> @@ -743,6 +743,7 @@
> #define mga_PCI_IDS \
> {0x102b, 0x0520, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
> {0x102b, 0x0521, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
> + {0x102b, 0x0533, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
> {0x102b, 0x0525, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G400}, \
> {0x102b, 0x2527, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G550}, \
> {0, 0, 0}
> --
> 2.9.2.368.g08bb350
>
Re: [PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned
On Wed, Jul 20, 2016 at 04:21:47PM +0100, Mel Gorman wrote:
> Page reclaim determines whether a pgdat is unreclaimable by examining how
> many pages have been scanned since a page was freed and comparing that
> to the LRU sizes. Skipped pages are not considered reclaim candidates but
> contribute to scanned. This can prematurely mark a pgdat as unreclaimable
> and trigger an OOM kill.
>
> While this does not fix an OOM kill message reported by Joonsoo Kim,
> it did stop pgdat being marked unreclaimable.
>
> Signed-off-by: Mel Gorman
> ---
> mm/vmscan.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 22aec2bcfeec..b16d578ce556 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1415,7 +1415,7 @@ static unsigned long isolate_lru_pages(unsigned long
> nr_to_scan,
> LIST_HEAD(pages_skipped);
>
> for (scan = 0; scan < nr_to_scan && nr_taken < nr_to_scan &&
> - !list_empty(src); scan++) {
> + !list_empty(src);) {
> struct page *page;
>
> page = lru_to_page(src);
> @@ -1429,6 +1429,9 @@ static unsigned long isolate_lru_pages(unsigned long
> nr_to_scan,
> continue;
> }
>
> + /* Pages skipped do not contribute to scan */
The comment should explain why.
/* Pages skipped do not contribute to scan to prevent premature OOM */
> + scan++;
> +
The one of my concern about node-lru is to add more lru lock contetion
in multiple zone system so such unbounded skip scanning under the lock
should have a limit to prevent latency spike and serialization of
current reclaim work.
Another concern is big mismatch between the number of pages from list and
LRU stat count because lruvec_lru_size call sites don't take the stat
under the lock while isolate_lru_pages moves many pages from lru list
to temporal skipped list.
> switch (__isolate_lru_page(page, mode)) {
> case 0:
> nr_pages = hpage_nr_pages(page);
> --
> 2.6.4
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
[PATCH] [linux-next] drm: Add a G200EH PCI id for HPE Proliant Gen9
Boot the system without this entry generates following warning.
fb: conflicting fb hw usage mgag200drmfb vs EFI VGA - removing generic driver
After apply this patch, no more conflict message.
fb: switching to mgag200drmfb from EFI VGA
Compile and tested on DL360 Gen9 and it works both console and X.
Signed-off-by: Masanari Iida
Suggested-by: Shane Seymour
---
include/drm/drm_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 8bc073d297db..3e16dfc2e08d 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -743,6 +743,7 @@
#define mga_PCI_IDS \
{0x102b, 0x0520, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
{0x102b, 0x0521, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
+ {0x102b, 0x0533, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G200}, \
{0x102b, 0x0525, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G400}, \
{0x102b, 0x2527, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G550}, \
{0, 0, 0}
--
2.9.2.368.g08bb350
Re: Fix issue with alternatives/paravirt patches
+++ Miroslav Benes [12/07/16 14:06 +0200]:
On Tue, 5 Jul 2016, Jessica Yu wrote:
Hi,
A few months ago, Chris Arges reported a bug involving alternatives/paravirt
patching that was discussed here [1] and here [2]. To briefly summarize the
bug, patch modules that contained .altinstructions or .parainstructions
sections would break because these alternative/paravirt patches would be
applied first by the module loader (see x86 module_finalize()), then
livepatch would later clobber these patches when applying per-object
relocations. This lead to crashes and unpredictable behavior.
One conclusion we reached from our last discussion was that we will
need to introduce some arch-specific code to address this problem.
This patchset presents a possible fix for the bug by adding a new
arch-specific arch_klp_init_object_loaded() function that by default
does nothing but can be overridden by different arches.
To fix this issue for x86, since we can access a patch module's Elf
sections through mod->klp_info, we can simply delay the calls to
apply_paravirt() and apply_alternatives() to arch_klp_init_object_loaded(),
which is called after relocations have been written for an object.
In addition, for patch modules, .parainstructions and .altinstructions are
prefixed by ".klp.arch.${objname}" so that the module loader ignores them
and livepatch can apply them manually.
Currently for kpatch, we don't support including jump table sections in
the patch module, and supporting .smp_locks is currently broken, so we
don't consider those sections (for now).
I did some light testing with some patches to kvm and verified that the
original issue reported in [2] was fixed.
Based on linux-next.
[1] http://thread.gmane.org/gmane.linux.kernel/2185604/
[2] https://github.com/dynup/kpatch/issues/580
Jessica Yu (2):
livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks
livepatch/x86: apply alternatives and paravirt patches after relocations
arch/x86/kernel/Makefile| 1 +
arch/x86/kernel/livepatch.c | 66 +
include/linux/livepatch.h | 3 +++
kernel/livepatch/core.c | 12 +++--
4 files changed, 80 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/kernel/livepatch.c
Hi,
thanks Jessica for implementing it. It does not look as bad as I was
afraid, which is great. Few remarks...
Is there a problem when you need to generate a dynrela for paravirt code?
I mean one does not know during the build of a patch module if paravirt
would or would not be applied. If such code needs to be relocated it could
be a problem for kpatch-build. Is this correct or am I missing something?
In kpatch-build, "special" sections like .parainstructions and
.altinstructions are into consideration. These sections are included
in the final patch module if they reference any of the new replacement
code. Like with any other section, kpatch-build will convert any relas
from .rela.parainstructions (for example) to dynrelas if it is
necessary. And with this patch we apply all "dynrelas" (which are now
actual relas in .klp.rela sections) first before applying any
paravirt/alternatives patches in arch_klp_init_object_loaded(), which
is the correct order.
Now the other architectures we support. s390 should be ok. There is
nothing much in module_finalize() there. powerpc is different though. It
is quite similar to x86_64 case. And also arm64 needs to be handled in
future.
Yeah, I think we are OK for s390, arm64 looks fairly straightforward
(just a call to apply_alternatives()), powerpc looks slightly more
involved but I haven't thoroughly dug into it yet.
So other arches will need to have arch_klp_init_object_loaded()
implemented eventually (if needed), but I think it is fine for now to
fix this issue on x86 first, since that's where the original bug
cropped up.
Jessica
[PATCH] reset: return -ENOTSUPP if CONFIG_RESET_CONTROLLER is undefined
This has been inconsistent; some returns -EINVAL, some -ENOTSUPP.
Make it consistent in this header, in favor of -ENOTSUPP.
Signed-off-by: Masahiro Yamada
---
include/linux/reset.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 5894f0f..c875b4b 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -71,14 +71,14 @@ static inline struct reset_control *__of_reset_control_get(
struct device_node *node,
const char *id, int index, int shared)
{
- return ERR_PTR(-EINVAL);
+ return ERR_PTR(-ENOTSUPP);
}
static inline struct reset_control *__devm_reset_control_get(
struct device *dev,
const char *id, int index, int shared)
{
- return ERR_PTR(-EINVAL);
+ return ERR_PTR(-ENOTSUPP);
}
#endif /* CONFIG_RESET_CONTROLLER */
--
1.9.1
[PATCH] reset: generate reset_control_get variants with macro expansion
The recent update in the reset subsystem requires all reset consumers
to be explicit about the requested reset lines; _explicit or _shared.
This effectively doubled the number of reset_control_get variants.
Also, we already had _optional variants.
We see some pattern in the reset_control_get APIs.
There are 6 base functions in terms of function prototype:
reset_control_get
reset_control_get_by_index
of_reset_control_get
of_reset_control_get_by_index
devm_reset_control_get
devm_reset_control_get_by_index
Each of them has 4 variants with the following suffixes:
_exclusive
_shared
_optional_exclusive
_optional_shared
The exhaustive set of functions (6 * 4) can be generated with macro
expansion. It will mitigate the pain of maintaining proliferating
APIs.
I merged similar comment blocks into two, for functions in core.c
because copy-paste work for similar comment blocks is error-prone.
Signed-off-by: Masahiro Yamada
---
drivers/reset/core.c | 36 ++
include/linux/reset.h | 306 +-
2 files changed, 86 insertions(+), 256 deletions(-)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index e21251d..dd536c3 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -257,6 +257,30 @@ static void __reset_control_put(struct reset_control *rstc)
kfree(rstc);
}
+/**
+ * __of_reset_control_get - Lookup and obtain a reference to a reset
controller.
+ * @node: device to be reset by the controller
+ * @id: optional reset line name
+ * @index: index of the reset line (valid iif @id is NULL)
+ * @shared: shareability of reset control
+ *
+ * Returns a struct reset_control or IS_ERR() condition containing errno.
+ * The target reset line can be specified by either @id or @index.
+ *
+ * Set the @shared flag for use with reset-controls which are shared between
+ * multiple hardware blocks. When a reset-control is shared, the behavior of
+ * reset_control_assert / deassert is changed; the reset-core will keep track
+ * of a deassert_count and only (re-)assert the reset after
reset_control_assert
+ * has been called as many times as reset_control_deassert was called. Calling
+ * reset_control_assert without first calling reset_control_deassert is not
+ * allowed on a shared reset control. Calling reset_control_reset is also not
+ * allowed on a shared reset control. Also see the remark about shared reset
+ * controls in the reset_control_assert docs.
+ *
+ * If the @shared flag is not set, this function gets an exclusive reference to
+ * a reset controller; if this function is called more then once for the same
+ * reset_control it will return -EBUSY.
+ */
struct reset_control *__of_reset_control_get(struct device_node *node,
const char *id, int index, int shared)
{
@@ -337,6 +361,18 @@ static void devm_reset_control_release(struct device *dev,
void *res)
reset_control_put(*(struct reset_control **)res);
}
+/**
+ * __devm_reset_control_get - resource managed __of_reset_control_get()
+ * @dev: device to be reset by the controller
+ * @id: optional reset line name
+ * @index: index of the reset line (valid iif @id is NULL)
+ * @shared: shareability of reset control
+ *
+ * Managed __of_reset_control_get(). For reset controllers returned from this
+ * function, reset_control_put() is called automatically on driver detach.
+ *
+ * See __of_reset_control_get() for more information.
+ */
struct reset_control *__devm_reset_control_get(struct device *dev,
const char *id, int index, int shared)
{
diff --git a/include/linux/reset.h b/include/linux/reset.h
index cb7db61..5894f0f 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -83,262 +83,56 @@ static inline struct reset_control
*__devm_reset_control_get(
#endif /* CONFIG_RESET_CONTROLLER */
-/**
- * reset_control_get_exclusive - Lookup and obtain an exclusive reference
- * to a reset controller.
- * @dev: device to be reset by the controller
- * @id: reset line name
- *
- * Returns a struct reset_control or IS_ERR() condition containing errno.
- * If this function is called more then once for the same reset_control it will
- * return -EBUSY.
- *
- * See reset_control_get_shared for details on shared references to
- * reset-controls.
- *
- * Use of id names is optional.
- */
-static inline struct reset_control *
-__must_check reset_control_get_exclusive(struct device *dev, const char *id)
-{
-#ifndef CONFIG_RESET_CONTROLLER
- WARN_ON(1);
-#endif
- return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
-}
-
-/**
- * reset_control_get_shared - Lookup and obtain a shared reference to a
- *reset controller.
- * @dev: device to be reset by the controller
- * @id: reset line name
- *
- * Returns a struct reset_control or IS_ERR() condition containing errno.
- * This function is intended for use
[gcc-4.4] Re: arch/x86/events/intel/uncore_snbep.o: warning: objtool: snbep_uncore_msr_enable_event()+0x2e: function has unreachable instruction
On Thu, Jul 21, 2016 at 11:06:06AM +0800, Liang, Kan wrote: Hi Fengguang, I located the unreachable instruction which is ud2. This instruction will raise invalid opcode exception. So I think normally it should not be reached. Also ud2 should be generated by compiler, not our codes. It's great to know that! I have no idea how to fix it. Have you met similar issue before? Do you have any suggestions? The warning shows up when we enabled gcc-4.4 for kernel build tests. It emits this "function has unreachable instruction" warning for ~1 kernel functions all over the places. So it must be a toolchain specific problem. Let's CC LKML and gcc lists for possible solutions. 0e0f : e0f: 55 push %rbp e10: 48 89 e5mov%rsp,%rbp e13: 53 push %rbx e14: 83 be 80 01 00 00 ffcmpl $0x,0x180(%rsi) e1b: 48 89 f3mov%rsi,%rbx e1e: 74 2b je e4b e20: 31 f6 xor%esi,%esi e22: e8 00 00 00 00 callq e27 e27: 48 89 c2mov%rax,%rdx e2a: 8b b3 78 01 00 00 mov0x178(%rbx),%esi e30: 48 c1 ea 20 shr$0x20,%rdx e34: 48 83 3d 00 00 00 00cmpq $0x0,0x0(%rip)# e3c e3b: 00 e3c: 75 02 jnee40 e3e: 0f 0b ud2 e40: 89 f7 mov%esi,%edi e42: 89 c6 mov%eax,%esi e44: ff 14 25 00 00 00 00callq *0x0 Thanks, Kan tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 47ef4ad2684d380dd6d596140fb79395115c3950 commit: 3b94a891667c30fb4624221497d77fc65d950345 perf/x86/intel/uncore: Remove SBOX support for Broadwell server date: 7 weeks ago config: x86_64-randconfig-s0-07191857 (attached as .config) compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7 reproduce: git checkout 3b94a891667c30fb4624221497d77fc65d950345 # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): >> arch/x86/events/intel/uncore_snbep.o: warning: objtool: snbep_uncore_msr_enable_event()+0x2e: function has unreachable instruction --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
linux-next: manual merge of the kvm tree with the powerpc tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/powerpc/kernel/Makefile
between commit:
27d114966735 ("powerpc/32: Remove RELOCATABLE_PPC32")
from the powerpc tree and commit:
fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on
HMI interrupt")
from the kvm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/kernel/Makefile
index 62df36c3f138,6972a23433d3..
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@@ -46,7 -41,8 +46,7 @@@ obj-$(CONFIG_VDSO32) += vdso32
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_ppc970.o cpu_setup_pa6t.o
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_power.o
- obj-$(CONFIG_PPC_BOOK3S_64) += mce.o mce_power.o
+ obj-$(CONFIG_PPC_BOOK3S_64) += mce.o mce_power.o hmi.o
-obj64-$(CONFIG_RELOCATABLE) += reloc_64.o
obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o idle_book3e.o
obj-$(CONFIG_PPC64) += vdso64/
obj-$(CONFIG_ALTIVEC) += vecemu.o
Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api
On 07/21/2016 11:53 AM, John Stultz wrote: After lots of debugging on an occasional DMA ERR issue, I realized that the desc structures which we point the dma hardware are being allocated out of regular memory. This means when we fill the desc structures, that data doesn't always get flushed out to memory by the time we start the dma transfer, resulting in the dma engine getting some null values, resulting in a DMA ERR on the first irq. How about using wmb() flush before start dma to sync desc? I remember I used dma_pool first, then do some optimization referring Russell's driver. Thanks
Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers
On Wed, Jul 20, 2016 at 06:37:07PM +0300, Thomas Backlund wrote: > > Yeah, but that patch seem to be heading to 4.8 only , so qat build > in upcoming 4.7 still breaks... > > and pulling that fix only to 4.7 breaks too, so I guess more fixes > would be needed for proper backport then... > > or are the qat fixes already queued somewhere for 4.7 final ? You're right. This patch is probably the safest fix for 4.7. I'll bounce it to stable. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH net-next v2 0/3] net: dsa: mv88e6xxx: rework EEPROM code
From: Vivien Didelot Date: Wed, 20 Jul 2016 18:18:33 -0400 > Some switches can access an optional external EEPROM via its registers. > > The 88E6352 family of switches have 8-bit address / 16-bit data access. > The new 88E6390 family has 16-bit address / 8-bit data access. > > This patchset cleans up the EEPROM code with 16-suffixed Global2 helpers > and makes it easy to add future support for 8-bit data EEPROM access. > > It also removes unnecessary mutexes and a few locked access functions. > > Changes in v2: > - add missing Signed-off-by tag Series applied, thanks.
Re: [PATCH v3 2/2] drm/mediatek: set mt8173 dithering function
Hi, Bibby:
On Thu, 2016-07-21 at 11:21 +0800, Bibby Hsieh wrote:
> Hi, CK
>
> I'm appreciate your comments.
>
>
[snip...]
> > >
> > > @@ -469,7 +484,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct
> > > mtk_ddp_comp *ovl)
> > > if (state->pending_config) {
> > > mtk_ddp_comp_config(ovl, state->pending_width,
> > > state->pending_height,
> > > - state->pending_vrefresh);
> > > + state->pending_vrefresh, 0);
> >
> > Why set bpc as 0 here? Maybe you have a assumption that OVL don't care
> > the bpc parameter. If one day OVL care it and we do not review here, the
> > bugs happen.
> >
> Pass 0 means don't care, I will modify mtk_od_config() and
> mtk_gamma_config() to filter this condition.
Using 0 as 'don't care' looks tricky. Please add comments to describe
this.
> > >
> > > state->pending_config = false;
> > > }
Regards,
CK
[PATCH 4/7] k3dma: Add cyclic mode for audio
From: Andy Green
Currently the k3dma driver doesn't offer the cyclic mode
necessary for handling audio.
This patch adds it.
Cc: Zhangfei Gao
Cc: Jingoo Han
Cc: Krzysztof Kozlowski
Cc: Maxime Ripard
Cc: Vinod Koul
Cc: Dan Williams
Cc: Mark Brown
Cc: Andy Green
Acked-by: Zhangfei Gao
Signed-off-by: Andy Green
[jstultz: Forward ported to mainline, removed a few
bits of logic that didn't seem to have much effect]
Signed-off-by: John Stultz
---
v2:
* Changed pr_debug() -> dev_debug() suggested by Zhangfei
---
drivers/dma/k3dma.c | 123 ++--
1 file changed, 109 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index c2906a82..8e4c845 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013 Linaro Ltd.
+ * Copyright (c) 2013 - 2015 Linaro Ltd.
* Copyright (c) 2013 Hisilicon Limited.
*
* This program is free software; you can redistribute it and/or modify
@@ -25,22 +25,27 @@
#define DRIVER_NAME"k3-dma"
#define DMA_MAX_SIZE 0x1ffc
+#define DMA_CYCLIC_MAX_PERIOD 0x1000
#define INT_STAT 0x00
#define INT_TC10x04
+#define INT_TC20x08
#define INT_ERR1 0x0c
#define INT_ERR2 0x10
#define INT_TC1_MASK 0x18
+#define INT_TC2_MASK 0x1c
#define INT_ERR1_MASK 0x20
#define INT_ERR2_MASK 0x24
#define INT_TC1_RAW0x600
+#define INT_TC2_RAW0x608
#define INT_ERR1_RAW 0x610
#define INT_ERR2_RAW 0x618
#define CH_PRI 0x688
#define CH_STAT0x690
#define CX_CUR_CNT 0x704
#define CX_LLI 0x800
-#define CX_CNT 0x810
+#define CX_CNT10x80c
+#define CX_CNT00x810
#define CX_SRC 0x814
#define CX_DST 0x818
#define CX_CFG 0x81c
@@ -49,6 +54,7 @@
#define CX_LLI_CHAIN_EN0x2
#define CX_CFG_EN 0x1
+#define CX_CFG_NODEIRQ BIT(1)
#define CX_CFG_MEM2PER (0x1 << 2)
#define CX_CFG_PER2MEM (0x2 << 2)
#define CX_CFG_SRCINCR (0x1 << 31)
@@ -81,6 +87,7 @@ struct k3_dma_chan {
enum dma_transfer_direction dir;
dma_addr_t dev_addr;
enum dma_status status;
+ boolcyclic;
};
struct k3_dma_phy {
@@ -134,6 +141,7 @@ static void k3_dma_terminate_chan(struct k3_dma_phy *phy,
struct k3_dma_dev *d)
val = 0x1 << phy->idx;
writel_relaxed(val, d->base + INT_TC1_RAW);
+ writel_relaxed(val, d->base + INT_TC2_RAW);
writel_relaxed(val, d->base + INT_ERR1_RAW);
writel_relaxed(val, d->base + INT_ERR2_RAW);
}
@@ -141,7 +149,7 @@ static void k3_dma_terminate_chan(struct k3_dma_phy *phy,
struct k3_dma_dev *d)
static void k3_dma_set_desc(struct k3_dma_phy *phy, struct k3_desc_hw *hw)
{
writel_relaxed(hw->lli, phy->base + CX_LLI);
- writel_relaxed(hw->count, phy->base + CX_CNT);
+ writel_relaxed(hw->count, phy->base + CX_CNT0);
writel_relaxed(hw->saddr, phy->base + CX_SRC);
writel_relaxed(hw->daddr, phy->base + CX_DST);
writel_relaxed(AXI_CFG_DEFAULT, phy->base + AXI_CFG);
@@ -175,11 +183,13 @@ static void k3_dma_enable_dma(struct k3_dma_dev *d, bool
on)
/* unmask irq */
writel_relaxed(0x, d->base + INT_TC1_MASK);
+ writel_relaxed(0x, d->base + INT_TC2_MASK);
writel_relaxed(0x, d->base + INT_ERR1_MASK);
writel_relaxed(0x, d->base + INT_ERR2_MASK);
} else {
/* mask irq */
writel_relaxed(0x0, d->base + INT_TC1_MASK);
+ writel_relaxed(0x0, d->base + INT_TC2_MASK);
writel_relaxed(0x0, d->base + INT_ERR1_MASK);
writel_relaxed(0x0, d->base + INT_ERR2_MASK);
}
@@ -192,24 +202,31 @@ static irqreturn_t k3_dma_int_handler(int irq, void
*dev_id)
struct k3_dma_chan *c;
u32 stat = readl_relaxed(d->base + INT_STAT);
u32 tc1 = readl_relaxed(d->base + INT_TC1);
+ u32 tc2 = readl_relaxed(d->base + INT_TC2);
u32 err1 = readl_relaxed(d->base + INT_ERR1);
u32 err2 = readl_relaxed(d->base + INT_ERR2);
u32 i, irq_chan = 0;
while (stat) {
i = __ffs(stat);
- stat &= (stat - 1);
- if (likely(tc1 & BIT(i))) {
+ stat &= ~BIT(i);
+ if (likely(tc1 & BIT(i)) || (tc2 & BIT(i))) {
+ unsigned long flags;
+
p = &d->phy[i];
c = p->vchan;
- if (c) {
- unsigned long flags;
-
+ if (c && (tc1
[PATCH 3/7] k3dma: Fix "nobody cared" message seen on any error
From: Andy Green
As it was before, as soon as the DMAC IP felt there was an error
he would return IRQ_NONE since no actual transfer had completed.
After spinning on that for 100K interrupts, Linux yanks the IRQ with
a "nobody cared" error.
This patch lets it handle the interrupt and keep the IRQ alive.
Cc: Zhangfei Gao
Cc: Jingoo Han
Cc: Krzysztof Kozlowski
Cc: Maxime Ripard
Cc: Vinod Koul
Cc: Dan Williams
Cc: Mark Brown
Cc: Andy Green
Acked-by: Zhangfei Gao
Signed-off-by: Andy Green
[jstultz: Forward ported to mainline]
Signed-off-by: John Stultz
---
drivers/dma/k3dma.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index 8dd050c..c2906a82 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -220,11 +220,13 @@ static irqreturn_t k3_dma_int_handler(int irq, void
*dev_id)
writel_relaxed(err1, d->base + INT_ERR1_RAW);
writel_relaxed(err2, d->base + INT_ERR2_RAW);
- if (irq_chan) {
+ if (irq_chan)
tasklet_schedule(&d->task);
+
+ if (irq_chan || err1 || err2)
return IRQ_HANDLED;
- } else
- return IRQ_NONE;
+
+ return IRQ_NONE;
}
static int k3_dma_start_txd(struct k3_dma_chan *c)
--
1.9.1
[PATCH 2/7] k3dma: Fix dma err offsets
From: Andy Green The offsets for ERR1 and ERR2 are wrong actually. That's why you can never clear an error. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green Acked-by: Zhangfei Gao Signed-off-by: Andy Green [jstultz: Forward ported to mainline] Signed-off-by: John Stultz --- drivers/dma/k3dma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c index d01a11d..8dd050c 100644 --- a/drivers/dma/k3dma.c +++ b/drivers/dma/k3dma.c @@ -34,8 +34,8 @@ #define INT_ERR1_MASK 0x20 #define INT_ERR2_MASK 0x24 #define INT_TC1_RAW0x600 -#define INT_ERR1_RAW 0x608 -#define INT_ERR2_RAW 0x610 +#define INT_ERR1_RAW 0x610 +#define INT_ERR2_RAW 0x618 #define CH_PRI 0x688 #define CH_STAT0x690 #define CX_CUR_CNT 0x704 -- 1.9.1
[PATCH 5/7] k3dma: Fix memory handling with cyclic mode
With cyclic mode, the shared virt-dma logic doesn't actually
manage the descriptor state, nor the calling of the descriptor
free callback. This results in leaking a desc structure every
time we start an audio transfer.
Thus we must manage it ourselves. The k3dma driver already keeps
track of the active and finished descriptors via ds_run and ds_done
pointers, so when we tear down everything in terminate_all, call
free_desc on the ds_run and ds_done pointers if they are not null.
NOTE: HiKey doesn't use the non-cyclic dma modes, so I'm not been
able to test those modes. But with this patch we no longer leak
the desc structures.
Cc: Zhangfei Gao
Cc: Jingoo Han
Cc: Krzysztof Kozlowski
Cc: Maxime Ripard
Cc: Vinod Koul
Cc: Dan Williams
Cc: Mark Brown
Cc: Andy Green
Signed-off-by: John Stultz
---
drivers/dma/k3dma.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index 8e4c845..950ed36 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -219,6 +219,7 @@ static irqreturn_t k3_dma_int_handler(int irq, void *dev_id)
spin_lock_irqsave(&c->vc.lock, flags);
vchan_cookie_complete(&p->ds_run->vd);
p->ds_done = p->ds_run;
+ p->ds_run = NULL;
spin_unlock_irqrestore(&c->vc.lock, flags);
}
if (c && (tc2 & BIT(i))) {
@@ -266,14 +267,14 @@ static int k3_dma_start_txd(struct k3_dma_chan *c)
* so vc->desc_issued only contains desc pending
*/
list_del(&ds->vd.node);
+
+ WARN_ON_ONCE(c->phy->ds_run);
+ WARN_ON_ONCE(c->phy->ds_done);
c->phy->ds_run = ds;
- c->phy->ds_done = NULL;
/* start dma */
k3_dma_set_desc(c->phy, &ds->desc_hw[0]);
return 0;
}
- c->phy->ds_done = NULL;
- c->phy->ds_run = NULL;
return -EAGAIN;
}
@@ -659,6 +660,15 @@ static int k3_dma_config(struct dma_chan *chan,
return 0;
}
+static void k3_dma_free_desc(struct virt_dma_desc *vd)
+{
+ struct k3_dma_desc_sw *ds =
+ container_of(vd, struct k3_dma_desc_sw, vd);
+
+ kfree(ds);
+}
+
+
static int k3_dma_terminate_all(struct dma_chan *chan)
{
struct k3_dma_chan *c = to_k3_chan(chan);
@@ -682,7 +692,15 @@ static int k3_dma_terminate_all(struct dma_chan *chan)
k3_dma_terminate_chan(p, d);
c->phy = NULL;
p->vchan = NULL;
- p->ds_run = p->ds_done = NULL;
+ if (p->ds_run) {
+ k3_dma_free_desc(&p->ds_run->vd);
+ p->ds_run = NULL;
+ }
+ if (p->ds_done) {
+ k3_dma_free_desc(&p->ds_done->vd);
+ p->ds_done = NULL;
+ }
+
}
spin_unlock_irqrestore(&c->vc.lock, flags);
vchan_dma_desc_free_list(&c->vc, &head);
@@ -735,14 +753,6 @@ static int k3_dma_transfer_resume(struct dma_chan *chan)
return 0;
}
-static void k3_dma_free_desc(struct virt_dma_desc *vd)
-{
- struct k3_dma_desc_sw *ds =
- container_of(vd, struct k3_dma_desc_sw, vd);
-
- kfree(ds);
-}
-
static const struct of_device_id k3_pdma_dt_ids[] = {
{ .compatible = "hisilicon,k3-dma-1.0", },
{}
--
1.9.1
[PATCH 0/7 v3] K3DMA fixes for HiKey HDMI audio
Per Mark's suggestion, I've split out the k3dma changes on their own as they are mostly fixes and the addition of cyclic mode. New in v3: * With inspiration from YongQin Liu, I figured out the reason we were seeing occasional DMA ERR issues: The desc structures were being allocated with kzalloc and so changes weren't necessarily being flushed to memory before the transfers started. I fixed this, but also uncoverd a memory leak that was happening in cyclic mode, so I fixed that as well. Thoughts and comments would be appreciated! thanks -john Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green Andy Green (4): k3dma: Fix hisi burst clipping k3dma: Fix dma err offsets k3dma: Fix "nobody cared" message seen on any error k3dma: Add cyclic mode for audio John Stultz (3): k3dma: Fix memory handling with cyclic mode k3dma: Fix occasional DMA ERR issue by using proper dma api Kconfig: Allow k3dma driver to be selected for more then HISI3xx platforms drivers/dma/Kconfig | 2 +- drivers/dma/k3dma.c | 219 ++-- 2 files changed, 181 insertions(+), 40 deletions(-) -- 1.9.1
[PATCH 1/7] k3dma: Fix hisi burst clipping
From: Andy Green Max burst len is a 4-bit field, but at the moment it's clipped with a 5-bit constant... reduce it to that which can be expressed Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Mark Brown Cc: Andy Green Acked-by: Zhangfei Gao Signed-off-by: Andy Green [jstultz: Forward ported to mainline] Signed-off-by: John Stultz --- drivers/dma/k3dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c index 1ba2fd7..d01a11d 100644 --- a/drivers/dma/k3dma.c +++ b/drivers/dma/k3dma.c @@ -552,7 +552,7 @@ static int k3_dma_config(struct dma_chan *chan, c->ccfg |= (val << 12) | (val << 16); if ((maxburst == 0) || (maxburst > 16)) - val = 16; + val = 15; else val = maxburst - 1; c->ccfg |= (val << 20) | (val << 24); -- 1.9.1
[PATCH 7/7] Kconfig: Allow k3dma driver to be selected for more then HISI3xx platforms
This allows the k3dma driver to be selected on HiKey via the ARCH_HISI dependency. Cc: Zhangfei Gao Cc: Jingoo Han Cc: Krzysztof Kozlowski Cc: Maxime Ripard Cc: Vinod Koul Cc: Dan Williams Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Wei Xu Cc: Rob Herring Cc: Andy Green Signed-off-by: John Stultz --- v2: * Use ARCH_HISI and COMPILE_TEST dependency, suggested by Mark Brown, instead of just removing all dependencies. --- drivers/dma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 8c98779..838b932 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -279,7 +279,7 @@ config INTEL_MIC_X100_DMA config K3_DMA tristate "Hisilicon K3 DMA support" - depends on ARCH_HI3xxx + depends on ARCH_HI3xxx || ARCH_HISI || COMPILE_TEST select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help -- 1.9.1
[PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api
After lots of debugging on an occasional DMA ERR issue, I realized
that the desc structures which we point the dma hardware are being
allocated out of regular memory. This means when we fill the desc
structures, that data doesn't always get flushed out to memory by
the time we start the dma transfer, resulting in the dma engine getting
some null values, resulting in a DMA ERR on the first irq.
Thus, this patch adopts mechanism similar to the zx296702_dma of
allocating the desc structures from a dma pool, so the memory caching
rules are properly set to avoid this issue.
Cc: Zhangfei Gao
Cc: Jingoo Han
Cc: Krzysztof Kozlowski
Cc: Maxime Ripard
Cc: Vinod Koul
Cc: Dan Williams
Cc: Mark Brown
Cc: Andy Green
Signed-off-by: John Stutlz
---
drivers/dma/k3dma.c | 58 ++---
1 file changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
index 950ed36..259bd3b 100644
--- a/drivers/dma/k3dma.c
+++ b/drivers/dma/k3dma.c
@@ -8,6 +8,8 @@
*/
#include
#include
+#include
+#include
#include
#include
#include
@@ -26,6 +28,7 @@
#define DRIVER_NAME"k3-dma"
#define DMA_MAX_SIZE 0x1ffc
#define DMA_CYCLIC_MAX_PERIOD 0x1000
+#define LLI_BLOCK_SIZE (4 * PAGE_SIZE)
#define INT_STAT 0x00
#define INT_TC10x04
@@ -74,7 +77,7 @@ struct k3_dma_desc_sw {
dma_addr_t desc_hw_lli;
size_t desc_num;
size_t size;
- struct k3_desc_hw desc_hw[0];
+ struct k3_desc_hw *desc_hw;
};
struct k3_dma_phy;
@@ -107,6 +110,7 @@ struct k3_dma_dev {
struct k3_dma_phy *phy;
struct k3_dma_chan *chans;
struct clk *clk;
+ struct dma_pool *pool;
u32 dma_channels;
u32 dma_requests;
};
@@ -434,6 +438,35 @@ static void k3_dma_fill_desc(struct k3_dma_desc_sw *ds,
dma_addr_t dst,
ds->desc_hw[num].config = ccfg;
}
+static struct k3_dma_desc_sw *k3_dma_alloc_desc_resource(int num,
+ struct dma_chan *chan)
+{
+ struct k3_dma_chan *c = to_k3_chan(chan);
+ struct k3_dma_desc_sw *ds;
+ struct k3_dma_dev *d = to_k3_dma(chan->device);
+ int lli_limit = LLI_BLOCK_SIZE / sizeof(struct k3_desc_hw);
+
+ if (num > lli_limit) {
+ dev_dbg(chan->device->dev, "vch %p: sg num %d exceed max %d\n",
+ &c->vc, num, lli_limit);
+ return NULL;
+ }
+
+ ds = kzalloc(sizeof(*ds), GFP_ATOMIC);
+ if (!ds)
+ return NULL;
+
+ ds->desc_hw = dma_pool_alloc(d->pool, GFP_NOWAIT, &ds->desc_hw_lli);
+ if (!ds->desc_hw) {
+ dev_dbg(chan->device->dev, "vch %p: dma alloc fail\n", &c->vc);
+ kfree(ds);
+ return NULL;
+ }
+ memset(ds->desc_hw, 0, sizeof(struct k3_desc_hw) * num);
+ ds->desc_num = num;
+ return ds;
+}
+
static struct dma_async_tx_descriptor *k3_dma_prep_memcpy(
struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
size_t len, unsigned long flags)
@@ -447,15 +480,14 @@ static struct dma_async_tx_descriptor *k3_dma_prep_memcpy(
return NULL;
num = DIV_ROUND_UP(len, DMA_MAX_SIZE);
- ds = kzalloc(sizeof(*ds) + num * sizeof(ds->desc_hw[0]), GFP_ATOMIC);
+
+ ds = k3_dma_alloc_desc_resource(num, chan);
if (!ds) {
dev_dbg(chan->device->dev, "vchan %p: kzalloc fail\n", &c->vc);
return NULL;
}
c->cyclic = 0;
- ds->desc_hw_lli = __virt_to_phys((unsigned long)&ds->desc_hw[0]);
ds->size = len;
- ds->desc_num = num;
num = 0;
if (!c->ccfg) {
@@ -506,12 +538,9 @@ static struct dma_async_tx_descriptor
*k3_dma_prep_slave_sg(
num += DIV_ROUND_UP(avail, DMA_MAX_SIZE) - 1;
}
- ds = kzalloc(sizeof(*ds) + num * sizeof(ds->desc_hw[0]), GFP_ATOMIC);
+ ds = k3_dma_alloc_desc_resource(num, chan);
if (!ds)
return NULL;
-
- ds->desc_hw_lli = __virt_to_phys((unsigned long)&ds->desc_hw[0]);
- ds->desc_num = num;
num = 0;
for_each_sg(sgl, sg, sglen, i) {
@@ -564,13 +593,10 @@ k3_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t
buf_addr,
if (avail > modulo)
num += DIV_ROUND_UP(avail, modulo) - 1;
- ds = kzalloc(sizeof(*ds) + num * sizeof(ds->desc_hw[0]), GFP_ATOMIC);
+ ds = k3_dma_alloc_desc_resource(num, chan);
if (!ds)
return NULL;
- ds->desc_hw_lli = __virt_to_phys((unsigned long)&ds->desc_hw[0]);
- ds->desc_num = num;
-
c->cyclic = 1;
addr = buf_addr;
avail = buf_len;
@@ -664,7 +690,9 @@ static void k3_dma_free_desc(struc
Re: [PATCH v2] watchdog: ziirave_wdt: Add support to upload the firmware.
On 07/20/2016 03:31 AM, Enric Balletbo i Serra wrote:
This patch adds and entry to the sysfs to start firmware upload process
on the specified device with the requested firmware.
The uploading of the firmware needs only to happen once per firmware
upgrade, as the firmware is stored in persistent storage. If the
firmware upload or the firmware verification fails then we print and
error message and exit.
Signed-off-by: Enric Balletbo i Serra
---
Changes since v1: (requested by Martyn)
- Remove two defines that are not used.
- Fix typo in documentation count -> length
drivers/watchdog/ziirave_wdt.c | 421 +
1 file changed, 421 insertions(+)
diff --git a/drivers/watchdog/ziirave_wdt.c b/drivers/watchdog/ziirave_wdt.c
index fa1efef..1a37577 100644
--- a/drivers/watchdog/ziirave_wdt.c
+++ b/drivers/watchdog/ziirave_wdt.c
@@ -18,7 +18,10 @@
* GNU General Public License for more details.
*/
+#include
+#include
#include
+#include
#include
#include
#include
@@ -36,6 +39,8 @@
#define ZIIRAVE_STATE_OFF 0x1
#define ZIIRAVE_STATE_ON 0x2
+#define ZIIRAVE_FW_NAME"ziirave_fw.hex"
+
static char *ziirave_reasons[] = {"power cycle", "hw watchdog", NULL, NULL,
"host request", NULL, "illegal configuration",
"illegal instruction", "illegal trap",
@@ -50,6 +55,25 @@ static char *ziirave_reasons[] = {"power cycle", "hw
watchdog", NULL, NULL,
#define ZIIRAVE_WDT_PING 0x9
#define ZIIRAVE_WDT_RESET_DURATION0xa
+#define ZIIRAVE_FIRM_PKT_TOTAL_SIZE20
+#define ZIIRAVE_FIRM_PKT_DATA_SIZE 16
+#define ZIIRAVE_FIRM_FLASH_MEMORY_START0x1600
+#define ZIIRAVE_FIRM_FLASH_MEMORY_END 0x2bbf
+
+/* Received and ready for next Download packet. */
+#define ZIIRAVE_FIRM_DOWNLOAD_ACK 1
+/* Currently writing to flash. Retry Download status in a moment! */
+#define ZIIRAVE_FIRM_DOWNLOAD_BUSY 2
+
+/* Firmware commands */
+#define ZIIRAVE_CMD_DOWNLOAD_START 0x10
+#define ZIIRAVE_CMD_DOWNLOAD_END 0x11
+#define ZIIRAVE_CMD_DOWNLOAD_SET_READ_ADDR 0x12
+#define ZIIRAVE_CMD_DOWNLOAD_READ_BYTE 0x13
+#define ZIIRAVE_CMD_RESET_PROCESSOR0x0b
+#define ZIIRAVE_CMD_JUMP_TO_BOOTLOADER 0x0c
+#define ZIIRAVE_CMD_DOWNLOAD_PACKET0x0e
+
struct ziirave_wdt_rev {
unsigned char major;
unsigned char minor;
@@ -62,6 +86,23 @@ struct ziirave_wdt_data {
int reset_reason;
};
+/*
+ * A packet to send to the firmware is composed by following bytes:
+ * Length | Addr0 | Addr1 | Data0 .. Data15 | Checksum |
+ * Where,
+ * Length: A data byte containing the length of the data.
+ * Addr0: Low byte of the address.
+ * Addr1: High byte of the address.
+ * Data0 .. Data15: Array of 16 bytes of data.
+ * Checksum: Checksum byte to verify data integrity.
+ */
+struct ziirave_fw_pkt_t {
+ u8 length;
+ u16 addr;
+ u8 data[ZIIRAVE_FIRM_PKT_DATA_SIZE];
+ u8 checksum;
+} __packed;
+
static int wdt_timeout;
module_param(wdt_timeout, int, 0);
MODULE_PARM_DESC(wdt_timeout, "Watchdog timeout in seconds");
@@ -146,6 +187,339 @@ static unsigned int ziirave_wdt_get_timeleft(struct
watchdog_device *wdd)
return ret;
}
+static int ziirave_firm_wait_for_ack(struct watchdog_device *wdd)
+{
+ struct i2c_client *client = to_i2c_client(wdd->parent);
+ int ret;
+
+ do {
+ usleep_range(5000, 5100);
+ ret = i2c_smbus_read_byte(client);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to read byte\n");
+ return ret;
+ }
+ } while (ret == ZIIRAVE_FIRM_DOWNLOAD_BUSY);
+
+ return ret == ZIIRAVE_FIRM_DOWNLOAD_ACK ? 0 : -EIO;
+}
+
+/*
+ * Parse Microchip format Hex file (an extended Intel Hex file) to extract
+ * address and data.
+ */
+static int ziirave_firm_parse_hex_line(unsigned char *fw_data,
+ struct ziirave_fw_pkt_t *fw_pkt,
+ bool *addr_has_changed)
+{
+ int count = 0;
+ unsigned char *src, dst;
+
+ if (*fw_data++ != ':')
+ return -EFAULT;
Why is this a bad address ? Something like -EINVAL might be more appropriate.
+
+ /* locate end of line */
+ for (src = fw_data; *src != '\n'; src += 2) {
What if there is no newline at the end ? What if fw_data is corrupt and
contains nonsense ?
To keep going until a non-hex character is found is not really robust.
+ /*
+* Convert the ascii hexadecimal string to its binary
+* representation
+*/
+ if (hex2bin(&dst, src, 1))
+ return -EINVAL;
+
+ /* Parse line to split addr / data */
+ switch (count) {
+
[PATCH 1/3] f2fs: support an ioctl to move a range of data blocks
This patch implements moving a range of data blocks from source file to
destination file.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h | 9
fs/f2fs/file.c | 132 +
2 files changed, 141 insertions(+)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c737854..7a57279 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -268,6 +268,8 @@ static inline bool __has_cursum_space(struct f2fs_journal
*journal,
#define F2FS_IOC_GARBAGE_COLLECT _IO(F2FS_IOCTL_MAGIC, 6)
#define F2FS_IOC_WRITE_CHECKPOINT _IO(F2FS_IOCTL_MAGIC, 7)
#define F2FS_IOC_DEFRAGMENT_IO(F2FS_IOCTL_MAGIC, 8)
+#define F2FS_IOC_MOVE_RANGE_IOWR(F2FS_IOCTL_MAGIC, 9, \
+ struct f2fs_move_range)
#define F2FS_IOC_SET_ENCRYPTION_POLICY FS_IOC_SET_ENCRYPTION_POLICY
#define F2FS_IOC_GET_ENCRYPTION_POLICY FS_IOC_GET_ENCRYPTION_POLICY
@@ -297,6 +299,13 @@ struct f2fs_defragment {
u64 len;
};
+struct f2fs_move_range {
+ u32 dst_fd; /* destination fd */
+ u64 pos_in; /* start position in src_fd */
+ u64 pos_out;/* start position in dst_fd */
+ u64 len;/* size to move */
+};
+
/*
* For INODE and NODE manager
*/
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 9f9cb64..0e493f6 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "f2fs.h"
#include "node.h"
@@ -2068,6 +2069,133 @@ out:
return err;
}
+static int f2fs_move_file_range(struct file *file_in, loff_t pos_in,
+ struct file *file_out, loff_t pos_out, size_t len)
+{
+ struct inode *src = file_inode(file_in);
+ struct inode *dst = file_inode(file_out);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(src);
+ size_t olen = len, dst_max_i_size = 0;
+ size_t dst_osize;
+ int ret;
+
+ if (file_in->f_path.mnt != file_out->f_path.mnt ||
+ src->i_sb != dst->i_sb)
+ return -EXDEV;
+
+ if (unlikely(f2fs_readonly(src->i_sb)))
+ return -EROFS;
+
+ if (S_ISDIR(src->i_mode) || S_ISDIR(dst->i_mode))
+ return -EISDIR;
+
+ if (f2fs_encrypted_inode(src) || f2fs_encrypted_inode(dst))
+ return -EOPNOTSUPP;
+
+ inode_lock(src);
+ if (src != dst)
+ inode_lock(dst);
+
+ ret = -EINVAL;
+ if (pos_in + len > src->i_size || pos_in + len < pos_in)
+ goto out_unlock;
+ if (len == 0)
+ olen = len = src->i_size - pos_in;
+ if (pos_in + len == src->i_size)
+ len = ALIGN(src->i_size, F2FS_BLKSIZE) - pos_in;
+ if (len == 0) {
+ ret = 0;
+ goto out_unlock;
+ }
+
+ dst_osize = dst->i_size;
+ if (pos_out + olen > dst->i_size)
+ dst_max_i_size = pos_out + olen;
+
+ /* verify the end result is block aligned */
+ if (!IS_ALIGNED(pos_in, F2FS_BLKSIZE) ||
+ !IS_ALIGNED(pos_in + len, F2FS_BLKSIZE) ||
+ !IS_ALIGNED(pos_out, F2FS_BLKSIZE))
+ goto out_unlock;
+
+ ret = f2fs_convert_inline_inode(src);
+ if (ret)
+ goto out_unlock;
+
+ ret = f2fs_convert_inline_inode(dst);
+ if (ret)
+ goto out_unlock;
+
+ /* write out all dirty pages from offset */
+ ret = filemap_write_and_wait_range(src->i_mapping,
+ pos_in, pos_in + len);
+ if (ret)
+ goto out_unlock;
+
+ ret = filemap_write_and_wait_range(dst->i_mapping,
+ pos_out, pos_out + len);
+ if (ret)
+ goto out_unlock;
+
+ f2fs_balance_fs(sbi, true);
+ f2fs_lock_op(sbi);
+ ret = __exchange_data_block(src, dst, pos_in,
+ pos_out, len >> F2FS_BLKSIZE_BITS, false);
+
+ if (!ret) {
+ if (dst_max_i_size)
+ f2fs_i_size_write(dst, dst_max_i_size);
+ else if (dst_osize != dst->i_size)
+ f2fs_i_size_write(dst, dst_osize);
+ }
+ f2fs_unlock_op(sbi);
+out_unlock:
+ if (src != dst)
+ inode_unlock(dst);
+ inode_unlock(src);
+ return ret;
+}
+
+static int f2fs_ioc_move_range(struct file *filp, unsigned long arg)
+{
+ struct f2fs_move_range range;
+ struct fd dst;
+ int err;
+
+ if (!(filp->f_mode & FMODE_READ) ||
+ !(filp->f_mode & FMODE_WRITE))
+ return -EBADF;
+
+ if (copy_from_user(&range, (struct f2fs_move_range __user *)arg,
+ sizeof(range)))
+ return -EFAULT;
+
+ dst = fdget(range.dst_fd);
+ if (!dst.file)
+
[PATCH 3/3] f2fs: handle error case with f2fs_bug_on
It's enough to show BUG or WARN by f2fs_bug_on for error case. Then, we don't need to remain corrupted filesystem. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index 5d4461f..9e652d5 100644 --- a/fs/f2fs/recovery.c +++ b/fs/f2fs/recovery.c @@ -482,6 +482,8 @@ static int do_recover_data(struct f2fs_sb_info *sbi, struct inode *inode, #endif /* We should not get -ENOSPC */ f2fs_bug_on(sbi, err); + if (err) + goto err; } /* Check the previous node page having this index */ -- 2.8.3
[PATCH 2/3] f2fs: avoid data race when deciding checkpoin in f2fs_sync_file
When fs utilization is almost full, f2fs_sync_file should do checkpoint if
there is not enough space for roll-forward later. (i.e. space_for_roll_forward)
So, currently we have no lock for sbi->alloc_valid_block_count, resulting in
race condition.
In rare case, we can get -ENOSPC when doing roll-forward which triggers
if (is_valid_blkaddr(sbi, dest, META_POR)) {
if (src == NULL_ADDR) {
err = reserve_new_block(&dn);
f2fs_bug_on(sbi, err);
...
}
...
}
in do_recover_data.
So, this patch avoids that situation in advance.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7a57279..3098109 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1147,24 +1147,33 @@ static inline void f2fs_i_blocks_write(struct inode *,
blkcnt_t, bool);
static inline bool inc_valid_block_count(struct f2fs_sb_info *sbi,
struct inode *inode, blkcnt_t *count)
{
+ blkcnt_t diff;
+
#ifdef CONFIG_F2FS_FAULT_INJECTION
if (time_to_inject(FAULT_BLOCK))
return false;
#endif
+ /*
+* let's increase this in prior to actual block count change in order
+* for f2fs_sync_file to avoid data races when deciding checkpoint.
+*/
+ percpu_counter_add(&sbi->alloc_valid_block_count, (*count));
+
spin_lock(&sbi->stat_lock);
sbi->total_valid_block_count += (block_t)(*count);
if (unlikely(sbi->total_valid_block_count > sbi->user_block_count)) {
- *count -= sbi->total_valid_block_count - sbi->user_block_count;
+ diff = sbi->total_valid_block_count - sbi->user_block_count;
+ *count -= diff;
sbi->total_valid_block_count = sbi->user_block_count;
if (!*count) {
spin_unlock(&sbi->stat_lock);
+ percpu_counter_sub(&sbi->alloc_valid_block_count, diff);
return false;
}
}
spin_unlock(&sbi->stat_lock);
f2fs_i_blocks_write(inode, *count, true);
- percpu_counter_add(&sbi->alloc_valid_block_count, (*count));
return true;
}
--
2.8.3
Re: [PATCH v2] block: do not merge requests without consulting with io scheduler
On 07/07/2016 12:48 PM, Tahsin Erdogan wrote: Before merging a bio into an existing request, io scheduler is called to get its approval first. However, the requests that come from a plug flush may get merged by block layer without consulting with io scheduler. In case of CFQ, this can cause fairness problems. For instance, if a request gets merged into a low weight cgroup's request, high weight cgroup now will depend on low weight cgroup to get scheduled. If high weigt cgroup needs that io request to complete before submitting more requests, then it will also lose its timeslice. Following script demonstrates the problem. Group g1 has a low weight, g2 and g3 have equal high weights but g2's requests are adjacent to g1's requests so they are subject to merging. Due to these merges, g2 gets poor disk time allocation. Looks (and seems) sane to me, no reason why the plug path should be different. Applied for 4.8, thanks. -- Jens Axboe
linux-next: manual merge of the device-mapper tree with the block tree
Hi all,
Today's linux-next merge of the device-mapper tree got a conflict in:
drivers/md/dm.c
between commit:
4cc96131afce ("dm: move request-based code out to dm-rq.[hc]")
from the block tree and commit:
70246286e94c ("block: get rid of bio_rw and READA")
from the device-mapper tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/md/dm.c
index 812fd5984eea,4dca5a792e4b..
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@@ -1684,512 -1141,165 +1141,165 @@@ static unsigned get_num_write_same_bios
return ti->num_write_same_bios;
}
- typedef bool (*is_split_required_fn)(struct dm_target *ti);
-
- static bool is_split_required_for_discard(struct dm_target *ti)
- {
- return ti->split_discard_bios;
- }
-
- static int __send_changing_extent_only(struct clone_info *ci,
- get_num_bios_fn get_num_bios,
- is_split_required_fn is_split_required)
- {
- struct dm_target *ti;
- unsigned len;
- unsigned num_bios;
-
- do {
- ti = dm_table_find_target(ci->map, ci->sector);
- if (!dm_target_is_valid(ti))
- return -EIO;
-
- /*
-* Even though the device advertised support for this type of
-* request, that does not mean every target supports it, and
-* reconfiguration might also have changed that since the
-* check was performed.
-*/
- num_bios = get_num_bios ? get_num_bios(ti) : 0;
- if (!num_bios)
- return -EOPNOTSUPP;
-
- if (is_split_required && !is_split_required(ti))
- len = min((sector_t)ci->sector_count,
max_io_len_target_boundary(ci->sector, ti));
- else
- len = min((sector_t)ci->sector_count,
max_io_len(ci->sector, ti));
-
- __send_duplicate_bios(ci, ti, num_bios, &len);
-
- ci->sector += len;
- } while (ci->sector_count -= len);
-
- return 0;
- }
-
- static int __send_discard(struct clone_info *ci)
- {
- return __send_changing_extent_only(ci, get_num_discard_bios,
- is_split_required_for_discard);
- }
-
- static int __send_write_same(struct clone_info *ci)
- {
- return __send_changing_extent_only(ci, get_num_write_same_bios, NULL);
- }
-
- /*
- * Select the correct strategy for processing a non-flush bio.
- */
- static int __split_and_process_non_flush(struct clone_info *ci)
- {
- struct bio *bio = ci->bio;
- struct dm_target *ti;
- unsigned len;
- int r;
-
- if (unlikely(bio_op(bio) == REQ_OP_DISCARD))
- return __send_discard(ci);
- else if (unlikely(bio_op(bio) == REQ_OP_WRITE_SAME))
- return __send_write_same(ci);
-
- ti = dm_table_find_target(ci->map, ci->sector);
- if (!dm_target_is_valid(ti))
- return -EIO;
-
- len = min_t(sector_t, max_io_len(ci->sector, ti), ci->sector_count);
-
- r = __clone_and_map_data_bio(ci, ti, ci->sector, &len);
- if (r < 0)
- return r;
-
- ci->sector += len;
- ci->sector_count -= len;
-
- return 0;
- }
-
- /*
- * Entry point to split a bio into clones and submit them to the targets.
- */
- static void __split_and_process_bio(struct mapped_device *md,
- struct dm_table *map, struct bio *bio)
- {
- struct clone_info ci;
- int error = 0;
-
- if (unlikely(!map)) {
- bio_io_error(bio);
- return;
- }
-
- ci.map = map;
- ci.md = md;
- ci.io = alloc_io(md);
- ci.io->error = 0;
- atomic_set(&ci.io->io_count, 1);
- ci.io->bio = bio;
- ci.io->md = md;
- spin_lock_init(&ci.io->endio_lock);
- ci.sector = bio->bi_iter.bi_sector;
-
- start_io_acct(ci.io);
-
- if (bio->bi_rw & REQ_PREFLUSH) {
- ci.bio = &ci.md->flush_bio;
- ci.sector_count = 0;
- error = __send_empty_flush(&ci);
- /* dec_pending submits any data associated with flush */
- } else {
- ci.bio = bio;
- ci.sector_count = bio_sectors(bio);
- while (ci.sector_count && !error)
- error = __split_and_process_non_flush(&ci);
- }
-
- /* drop the extra reference count */
- dec_pending(ci.io, error);
- }
- /*---
Re: [PATCH v3 1/2] drm/mediatek: Add gamma correction
Hi, CK
I'm appreciate your comments.
On Fri, 2016-07-15 at 17:11 +0800, CK Hu wrote:
> Hi, Bibby:
>
> Some comments inline.
>
> On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote:
> > Apply gamma function to correct brightness values.
> > It applies arbitrary mapping curve to compensate the
> > incorrect transfer function of the panel.
> >
> > Signed-off-by: Bibby Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 +++
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 89
> > ++-
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 +++
> > 4 files changed, 106 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..ee219bb 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -409,6 +409,10 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
> > *crtc,
> > }
> > if (pending_planes)
> > mtk_crtc->pending_planes = true;
> > + if (crtc->state->color_mgmt_changed)
> > + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> > +
> > }
> >
> > static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > @@ -418,6 +422,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > .reset = mtk_drm_crtc_reset,
> > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > .atomic_destroy_state = mtk_drm_crtc_destroy_state,
> > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> > };
> >
> > static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > @@ -569,6 +574,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > if (ret < 0)
> > goto unprepare;
> >
> > + drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
> > + drm_helper_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> > + MTK_LUT_SIZE);
> > priv->crtc[pipe] = &mtk_crtc->base;
> > priv->num_pipes++;
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > index 81e5566..d332564 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > @@ -19,6 +19,7 @@
> > #include "mtk_drm_plane.h"
> >
> > #define OVL_LAYER_NR 4
> > +#define MTK_LUT_SIZE 512
> >
> > int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
> > void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int
> > pipe);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 3970fcf..56c5894 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -24,6 +24,7 @@
> > #include "mtk_drm_drv.h"
> > #include "mtk_drm_plane.h"
> > #include "mtk_drm_ddp_comp.h"
> > +#include "mtk_drm_crtc.h"
> >
> > #define DISP_OD_EN 0x
> > #define DISP_OD_INTEN 0x0008
> > @@ -38,6 +39,21 @@
> > #define DISP_COLOR_WIDTH 0x0c50
> > #define DISP_COLOR_HEIGHT 0x0c54
> >
> > +#define DISP_AAL_EN0x000
> > +#define DISP_AAL_SIZE 0x030
> > +
> > +#define DISP_GAMMA_EN 0x000
> > +#define DISP_GAMMA_CFG 0x020
> > +#define DISP_GAMMA_SIZE0x030
> > +#define DISP_GAMMA_LUT 0x700
>
> It's better that the digits of register address of OD, COLOR, AAL, and
> GAMMA are the same. Maybe you can align all to 4 digits.
>
Ok, will fix.
> > +
> > +#define LUT_10BIT_MASK 0x3ff
> > +
> > +#define AAL_EN BIT(0)
> > +
> > +#define GAMMA_EN BIT(0)
> > +#define GAMMA_LUT_EN BIT(1)
> > +
> > #defineOD_RELAY_MODE BIT(0)
> >
> > #defineUFO_BYPASS BIT(2)
> > @@ -76,6 +92,61 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
> > writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
> > }
> >
> > +static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
> > + unsigned int h, unsigned int vrefresh)
> > +{
> > + writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
> > +}
> > +
> > +static void mtk_aal_start(struct mtk_ddp_comp *comp)
> > +{
> > + writel(AAL_EN, comp->regs + DISP_AAL_EN);
> > +}
> > +
> > +static void mtk_aal_stop(struct mtk_ddp_comp *comp)
> > +{
> > + writel_relaxed(0x0, comp->regs + DISP_AAL_EN);
> > +}
>
> I think AAL is somewhat different from GAMMA and this patch include 3
> modifications:
>
>
Re: [PATCH v3 2/2] drm/mediatek: set mt8173 dithering function
Hi, CK
I'm appreciate your comments.
On Mon, 2016-07-18 at 10:33 +0800, CK Hu wrote:
> Hi, Bibby:
>
> Some comments inline.
>
> On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote:
> > Some panels only accept bpc (bit per color) 6-bit.
> > But, the default bpc in mt8173 display data path is 8-bit.
> > If we didn't enable dithering function to convert bpc,
> > display cannot show the smooth grayscale image.
> >
> > In mt8173, the dithering function in OD (OverDrive) and
> > GAMMA module, we have to config them with
> > connector->display_mode.bpc when CRTC initial.
> >
> > 1. Clear the default value at *_DITHER_5 and *_DITHER_7 register.
> > 2. Calculate the LSB_ERR_SHIFT bits and ADD_LSHIFT bits two values.
> > i.e. Input bpc of OD is 10 bits, we assume the bpc of panel is 6-bit,
> > so, we need to set 4-bit to LSB_ERR_SHIFT and ADD_LSHIFT bits respectively.
> > 3. Then, set the OD or GAMMA to dithering mode depends on path-1 or path-2.
> >
> > Signed-off-by: Bibby Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +-
> > drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +-
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 21 ++--
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 77
> > +++
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |6 +--
> > 5 files changed, 92 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 8f62671f..019b7ca 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -103,7 +103,8 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
> > }
> >
> > static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
> > - unsigned int h, unsigned int vrefresh)
> > + unsigned int h, unsigned int vrefresh,
> > + unsigned int bpc)
> > {
> > if (w != 0 && h != 0)
> > writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > index 5fb80cb..0df05f9 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > @@ -106,7 +106,8 @@ static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
> > }
> >
> > static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
> > - unsigned int height, unsigned int vrefresh)
> > + unsigned int height, unsigned int vrefresh,
> > + unsigned int bpc)
> > {
> > unsigned int threshold;
> > unsigned int reg;
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index ee219bb..18c9d0d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -222,7 +222,9 @@ static void mtk_crtc_ddp_clk_disable(struct
> > mtk_drm_crtc *mtk_crtc)
> > static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> > {
> > struct drm_crtc *crtc = &mtk_crtc->base;
> > - unsigned int width, height, vrefresh;
> > + struct drm_connector *connector;
> > + struct drm_encoder *encoder;
> > + unsigned int width, height, vrefresh, bpc = 0;
> > int ret;
> > int i;
> >
> > @@ -234,6 +236,19 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> > *mtk_crtc)
> > height = crtc->state->adjusted_mode.vdisplay;
> > vrefresh = crtc->state->adjusted_mode.vrefresh;
> >
> > + drm_for_each_encoder(encoder, crtc->dev) {
> > + if (encoder->crtc != crtc)
> > + continue;
> > +
> > + drm_for_each_connector(connector, crtc->dev) {
> > + if (connector->encoder != encoder)
> > + continue;
> > + if (connector->display_info.bpc >= 3 &&
>
> I think you should left this HW constrain in mtk_od_config() and
> mtk_gamma_config(). Here just calculate the expected bpc.
>
Ok, I will do that.
> > + (bpc == 0 || bpc > connector->display_info.bpc))
>
> I think bpc should be initialized as HW default bpc and you can remove
> this condiction 'bpc == 0' because we should set bpc to HW default bpc
> while all connnector bpc is greater than HW default bpc.
>
Ok, will do.
> > + bpc = connector->display_info.bpc;
> > + }
> > + }
> > +
> > ret = pm_runtime_get_sync(crtc->dev->dev);
> > if (ret < 0) {
> > DRM_ERROR("Failed to enable power domain: %d\n", ret);
> > @@ -266,7 +281,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> > *mtk_crtc)
> > for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> > struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
> >
> > - mtk_ddp_comp_config(comp, width, height, vrefresh);
> >
[PATCH] s390/perf: fix 'start' address of module's map
At preset, when creating module's map, perf gets 'start' address by parsing
'/proc/modules', but it's module base address, isn't the start address of
'.text' section. In most archs, it's OK. But for s390, it places 'GOT' and
'PLT' relocations before '.text' section. So there exists an offset between
module base address and '.text' section, which will incur wrong symbol
resolution for modules.
Fix this bug by getting 'start' address of module's map from parsing
'/sys/module/[module name]/sections/.text', not from '/proc/modules'.
Signed-off-by: Song Shan Gong
Acked-by: Jiri Olsa
---
tools/perf/arch/s390/util/Build | 2 ++
tools/perf/arch/s390/util/machine.c | 19 +++
tools/perf/util/machine.c | 8
tools/perf/util/machine.h | 1 +
4 files changed, 30 insertions(+)
create mode 100644 tools/perf/arch/s390/util/machine.c
diff --git a/tools/perf/arch/s390/util/Build b/tools/perf/arch/s390/util/Build
index 8a61372..5bd7b92 100644
--- a/tools/perf/arch/s390/util/Build
+++ b/tools/perf/arch/s390/util/Build
@@ -2,3 +2,5 @@ libperf-y += header.o
libperf-y += kvm-stat.o
libperf-$(CONFIG_DWARF) += dwarf-regs.o
+
+libperf-y += machine.o
diff --git a/tools/perf/arch/s390/util/machine.c
b/tools/perf/arch/s390/util/machine.c
new file mode 100644
index 000..b9a95a1
--- /dev/null
+++ b/tools/perf/arch/s390/util/machine.c
@@ -0,0 +1,19 @@
+#include
+#include
+#include
+#include "util.h"
+#include "machine.h"
+#include "api/fs/fs.h"
+
+int arch__fix_module_text_start(u64 *start, const char *name)
+{
+ char path[PATH_MAX];
+
+ snprintf(path, PATH_MAX, "module/%.*s/sections/.text",
+ (int)strlen(name) - 2, name + 1);
+
+ if (sysfs__read_ull(path, (unsigned long long *)start) < 0)
+ return -1;
+
+ return 0;
+}
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index b177218..97cc9f0 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1091,12 +1091,20 @@ static int machine__set_modules_path(struct machine
*machine)
return map_groups__set_modules_path_dir(&machine->kmaps, modules_path,
0);
}
+int __weak arch__fix_module_text_start(u64 *start __maybe_unused,
+ const char *name __maybe_unused)
+{
+ return 0;
+}
static int machine__create_module(void *arg, const char *name, u64 start)
{
struct machine *machine = arg;
struct map *map;
+ if (arch__fix_module_text_start(&start, name) < 0)
+ return -1;
+
map = machine__findnew_module_map(machine, start, name);
if (map == NULL)
return -1;
diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
index 41ac9cf..20739f7 100644
--- a/tools/perf/util/machine.h
+++ b/tools/perf/util/machine.h
@@ -216,6 +216,7 @@ struct symbol *machine__find_kernel_function_by_name(struct
machine *machine,
struct map *machine__findnew_module_map(struct machine *machine, u64 start,
const char *filename);
+int arch__fix_module_text_start(u64 *start, const char *name);
int __machine__load_kallsyms(struct machine *machine, const char *filename,
enum map_type type, bool no_kcore, symbol_filter_t
filter);
--
2.3.0
[RFC PATCH V4]s390/perf:fix 'start' address of module's map
Change log: >From V3: 1.move fixup function to tools/perf/arch/s390/util/machine.c; 2. Add acked-by info from Jiri Olsa ; >From V2: 1. remove redundancy string 'module_name'; >From V1: 1.change func name from 'fix__arch_module_baseaddr' to 'fix__arch_module_text_start'; 2.Parse '.text' start addr from 'sys' through 'sysfs__read_ull', not 'hex2u64()'; 2.Perfect code: check return value and allocated pointer by 'strdup'. Song Shan Gong (1): s390/perf: fix 'start' address of module's map tools/perf/arch/s390/util/Build | 2 ++ tools/perf/arch/s390/util/sym-handling.c | 27 +++ tools/perf/util/machine.c| 8 tools/perf/util/machine.h| 1 + 4 files changed, 38 insertions(+) create mode 100644 tools/perf/arch/s390/util/sym-handling.c -- 2.3.0
linux-next: manual merge of the block tree with Linus' tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
block/blk-lib.c
between commit:
05bd92dddc59 ("block: missing bio_put following submit_bio_wait")
from Linus' tree and commit:
4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc block/blk-lib.c
index 9e29dc351695,e371f83a3186..
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@@ -103,17 -116,13 +116,14 @@@ int blkdev_issue_discard(struct block_d
struct blk_plug plug;
int ret;
- if (flags & BLKDEV_DISCARD_SECURE)
- type |= REQ_SECURE;
-
blk_start_plug(&plug);
- ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, type,
+ ret = __blkdev_issue_discard(bdev, sector, nr_sects, gfp_mask, flags,
&bio);
if (!ret && bio) {
- ret = submit_bio_wait(type, bio);
- if (ret == -EOPNOTSUPP)
+ ret = submit_bio_wait(bio);
+ if (ret == -EOPNOTSUPP && !(flags & BLKDEV_DISCARD_ZERO))
ret = 0;
+ bio_put(bio);
}
blk_finish_plug(&plug);
@@@ -166,11 -176,9 +177,11 @@@ int blkdev_issue_write_same(struct bloc
}
}
- if (bio)
+ if (bio) {
- ret = submit_bio_wait(REQ_WRITE | REQ_WRITE_SAME, bio);
+ ret = submit_bio_wait(bio);
+ bio_put(bio);
+ }
- return ret != -EOPNOTSUPP ? ret : 0;
+ return ret;
}
EXPORT_SYMBOL(blkdev_issue_write_same);
@@@ -209,11 -217,8 +220,11 @@@ static int __blkdev_issue_zeroout(struc
}
}
- if (bio)
- return submit_bio_wait(bio);
+ if (bio) {
- ret = submit_bio_wait(WRITE, bio);
++ ret = submit_bio_wait(bio);
+ bio_put(bio);
+ return ret;
+ }
return 0;
}
Re: dm stripe: add DAX support
On 07/20/2016 06:01 PM, Mike Snitzer wrote: On Wed, Jul 13 2016 at 11:03am -0400, Kani, Toshimitsu wrote: On Tue, 2016-07-12 at 22:01 -0400, Mike Snitzer wrote: On Tue, Jul 12 2016 at 6:22pm -0400, Kani, Toshimitsu wrote: On Fri, 2016-06-24 at 14:29 -0400, Mike Snitzer wrote: : Thanks for putting this summary together. Unfortunately none of the DM changes can be queued for 4.8 until Jens takes the 2 block core patches: https://patchwork.kernel.org/patch/9196021/ https://patchwork.kernel.org/patch/9196019/ Not sure what the hold up and/or issue is with them. But I've asked twice (and implicilty a 3rd time here). Hopefully they land in time for 4.8. Hi Jens, Can you take the two patches above? These patches add QUEUE_FLAG_DAX and its sysfs show func. They allow device-mapper to set dax-capability based on its configuration, and also allow user applications to check dax-capability via sysfs. Hi Jens, As I shared with you before, here are the 2 patches I staged in linux-next via linux-dm.git's 'for-next' (same as in the patchwork references above) -- these were staged just so we had linux-next coverage until you picked them up. Please pick these up for 4.8 -- the changes are straightforward, are required for DM's DAX support, and Dan Williams has also acked them: https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=6c00531c6affa42b165df73a1eac3289bc45f4c4 https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=51d1a5abcd0e88cb4528f35643245ea59cf234f1 Feel free to pick them up from patchwork or cherry-pick from linux-dm.git Added for 4.8, thanks! -- Jens Axboe
Re: [PATCH v8 3/3] arm64: dts: rockchip: add usb2-phy support for rk3399
Hi Doug,
On 2016/7/21 5:33, Doug Anderson wrote:
Hi,
On Tue, Jul 19, 2016 at 12:28 AM, Frank Wang wrote:
You need a patch description here, even for simple patches. All you
have now is a subject.
OK, I will describe it next version.
Signed-off-by: Frank Wang
---
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 19 +++
arch/arm64/boot/dts/rockchip/rk3399.dtsi| 47 ++-
Personally I'd prefer to see EVB in a separate patch.
Yep, I would like to separate them :-) .
2 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index 1a3eb14..31d4828 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -69,6 +69,15 @@
regulator-max-microvolt = <330>;
};
+ vbus_host: vbus-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vbus_host";
+ };
+
To match my schematics, this would probably be "vcc5v0_host".
Technically there are two regulators but since they are the same
voltage and enabled by the same GPIO it seems like modeling it as one
regulator is fine.
Yep, you are right, I will rename it.
If you really wanted to model things you could also include the input
supply (VCC5V0_SYS). Not sure how much you care to model in EVB.
Actually, from
"Documentation/devicetree/bindings/regulator/fixed-regulator.txt" show,
input supply name is just optional property, and it seems that only do
assign "vin" value for input_supply (the second member of struct
fixed_voltage_config) if "vin-supply" is specified.
So is input supply name (VCC5V0_SYS) required here? Would you like to
give more comments please?
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
@@ -93,6 +102,16 @@
status = "okay";
};
+&u2phy0_host {
+ phy-supply = <&vbus_host>;
+ status = "okay";
+};
+
+&u2phy1_host {
+ phy-supply = <&vbus_host>;
+ status = "okay";
+};
+
Technically "u2" sorts alphabetically before "uart".
Well, It will be sorted next version.
&usb_host0_ehci {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d7f8e06..0383785 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -221,6 +221,8 @@
interrupts = ;
clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>;
clock-names = "hclk_host0", "hclk_host0_arb";
+ phys = <&u2phy0_host>;
+ phy-names = "u2phy0";
This is wrong. From
"Documentation/devicetree/bindings/usb/usb-ehci.txt" phy-names should
be "usb".
done.
status = "disabled";
};
@@ -239,6 +241,8 @@
interrupts = ;
clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>;
clock-names = "hclk_host1", "hclk_host1_arb";
+ phys = <&u2phy1_host>;
+ phy-names = "u2phy1";
This is wrong. From
"Documentation/devicetree/bindings/usb/usb-ehci.txt" phy-names should
be "usb".
done
status = "disabled";
};
@@ -481,8 +485,42 @@
};
grf: syscon@ff77 {
- compatible = "rockchip,rk3399-grf", "syscon";
+ compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
reg = <0x0 0xff77 0x0 0x1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ u2phy0: usb2-phy@e450 {
+ compatible = "rockchip,rk3399-usb2phy";
+ reg = <0xe450 0x10>;
+ clocks = <&cru SCLK_USB2PHY0_REF>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ clock-output-names = "clk_usbphy0_480m";
Any reason why there isn't a 'status = "disabled";' here?
Refer to some explains from Heiko in another mail which sent at 6:07 AM
on 21th July, anyway, I will add ' status = "disabled" ' property next
version.
+ u2phy0_host: host-port {
+ #phy-cells = <0>;
+ interrupts = ;
+ interrupt-names = "linestate";
+ status = "disabled";
+ };
+ };
+
+ u2phy1: usb2-phy@e460 {
+ compatible = "rockchip,rk3399-usb2phy";
+ reg = <0xe460 0x10>;
+ clocks = <&cru SCLK_USB2PHY1_REF>;
linux-next: manual merge of the kspp tree with the arm64 tree
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
arch/arm64/include/asm/uaccess.h
between commit:
bffe1baff5d5 ("arm64: kasan: instrument user memory access API")
from the arm64 tree and commit:
aac380fe78b1 ("arm64/uaccess: Enable hardened usercopy")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/include/asm/uaccess.h
index 5e834d10b291,c3d445b42351..
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@@ -264,33 -276,32 +264,38 @@@ extern unsigned long __must_check __cle
static inline unsigned long __must_check __copy_from_user(void *to, const
void __user *from, unsigned long n)
{
+ kasan_check_write(to, n);
- return __arch_copy_from_user(to, from, n);
+ check_object_size(to, n, false);
+ return __arch_copy_from_user(to, from, n);
}
static inline unsigned long __must_check __copy_to_user(void __user *to,
const void *from, unsigned long n)
{
+ kasan_check_read(from, n);
- return __arch_copy_to_user(to, from, n);
+ check_object_size(from, n, true);
+ return __arch_copy_to_user(to, from, n);
}
static inline unsigned long __must_check copy_from_user(void *to, const void
__user *from, unsigned long n)
{
+ kasan_check_write(to, n);
+
- if (access_ok(VERIFY_READ, from, n))
+ if (access_ok(VERIFY_READ, from, n)) {
+ check_object_size(to, n, false);
n = __arch_copy_from_user(to, from, n);
- else /* security hole - plug it */
+ } else /* security hole - plug it */
memset(to, 0, n);
return n;
}
static inline unsigned long __must_check copy_to_user(void __user *to, const
void *from, unsigned long n)
{
+ kasan_check_read(from, n);
+
- if (access_ok(VERIFY_WRITE, to, n))
+ if (access_ok(VERIFY_WRITE, to, n)) {
+ check_object_size(from, n, true);
n = __arch_copy_to_user(to, from, n);
+ }
return n;
}
Re: [PATCH net-next] net: dsa: add CONFIG_NET_DSA_LEGACY
Le 20/07/2016 à 17:35, Andrew Lunn a écrit : > On Wed, Jul 20, 2016 at 06:26:41PM -0400, Vivien Didelot wrote: >> This patch simply moves the legacy DSA code from dsa.c to legacy.c, >> except the few shared symbols which remain in dsa.c. > > I think it is a bit early for this. Lets convert all in kernel users > to the new binding first. Fine with me, let's try to get the in-tree DTS files converted to the new binding by v4.9 so we can then introduce this Kconfig symbol and start producing warnings if the old binding is encountered, how does that sound? -- Florian
Re: [PATCH v13 00/12] support "task_isolation" mode
We are trying to test the patchset on x86 and are getting strange backtraces and aborts. It seems that the cpu before the cpu we are running on creates an irq_work event that causes a latency event on the next cpu. This is weird. Is there a new round robin IPI feature in the kernel that I am not aware of? Backtraces from dmesg: [ 956.603223] latencytest/7928: task_isolation mode lost due to irq_work [ 956.610817] cpu 12: irq_work violating task isolation for latencytest/7928 on cpu 13 [ 956.619985] CPU: 12 PID: 0 Comm: swapper/12 Not tainted 4.7.0-rc7-stream1 #1 [ 956.628765] Hardware name: Dell Inc. PowerEdge R630/0CNCJW, BIOS 2.0.2 03/15/2016 [ 956.637642] 0086 ce6735c7b39e7b81 88103e783d00 8134f6ff [ 956.646739] 88102c50d700 000d 88103e783d28 811986f4 [ 956.655828] 88102c50d700 88203cf97f80 000d 88103e783d68 [ 956.664924] Call Trace: [ 956.667945][] dump_stack+0x63/0x84 [ 956.674740] [] task_isolation_debug_task+0xb4/0xd0 [ 956.682229] [] _task_isolation_debug+0x83/0xc0 [ 956.689331] [] irq_work_queue_on+0x9c/0x120 [ 956.696142] [] tick_nohz_full_kick_cpu+0x44/0x50 [ 956.703438] [] wake_up_nohz_cpu+0x99/0x110 [ 956.710150] [] internal_add_timer+0x71/0xb0 [ 956.716959] [] add_timer_on+0xbb/0x140 [ 956.723283] [] clocksource_watchdog+0x230/0x300 [ 956.730480] [] ? __clocksource_unstable.isra.2+0x40/0x40 [ 956.738555] [] call_timer_fn+0x35/0x120 [ 956.744973] [] ? __clocksource_unstable.isra.2+0x40/0x40 [ 956.753046] [] run_timer_softirq+0x23c/0x2f0 [ 956.759952] [] __do_softirq+0xd7/0x2c5 [ 956.766272] [] irq_exit+0xf5/0x100 [ 956.772209] [] smp_apic_timer_interrupt+0x42/0x50 [ 956.779600] [] apic_timer_interrupt+0x8c/0xa0 [ 956.786602][] ? poll_idle+0x40/0x80 [ 956.793490] [] cpuidle_enter_state+0x9c/0x260 [ 956.800498] [] cpuidle_enter+0x17/0x20 [ 956.806810] [] cpu_startup_entry+0x2b7/0x3a0 [ 956.813717] [] start_secondary+0x15c/0x1a0 [ 1036.601758] cpu 12: irq_work violating task isolation for latencytest/8447 on cpu 13 [ 1036.610922] CPU: 12 PID: 0 Comm: swapper/12 Not tainted 4.7.0-rc7-stream1 #1 [ 1036.619692] Hardware name: Dell Inc. PowerEdge R630/0CNCJW, BIOS 2.0.2 03/15/2016 [ 1036.628551] 0086 ce6735c7b39e7b81 88103e783d00 8134f6ff [ 1036.637648] 88102dca 000d 88103e783d28 811986f4 [ 1036.646741] 88102dca 88203cf97f80 000d 88103e783d68 [ 1036.655833] Call Trace: [ 1036.658852][] dump_stack+0x63/0x84 [ 1036.665649] [] task_isolation_debug_task+0xb4/0xd0 [ 1036.673136] [] _task_isolation_debug+0x83/0xc0 [ 1036.680237] [] irq_work_queue_on+0x9c/0x120 [ 1036.687091] [] tick_nohz_full_kick_cpu+0x44/0x50 [ 1036.694388] [] wake_up_nohz_cpu+0x99/0x110 [ 1036.701089] [] internal_add_timer+0x71/0xb0 [ 1036.707896] [] add_timer_on+0xbb/0x140 [ 1036.714210] [] clocksource_watchdog+0x230/0x300 [ 1036.721411] [] ? __clocksource_unstable.isra.2+0x40/0x40 [ 1036.729478] [] call_timer_fn+0x35/0x120 [ 1036.735899] [] ? __clocksource_unstable.isra.2+0x40/0x40 [ 1036.743970] [] run_timer_softirq+0x23c/0x2f0 [ 1036.750878] [] __do_softirq+0xd7/0x2c5 [ 1036.757199] [] irq_exit+0xf5/0x100 [ 1036.763132] [] smp_apic_timer_interrupt+0x42/0x50 [ 1036.770520] [] apic_timer_interrupt+0x8c/0xa0 [ 1036.777520][] ? poll_idle+0x40/0x80 [ 1036.784410] [] cpuidle_enter_state+0x9c/0x260 [ 1036.791413] [] cpuidle_enter+0x17/0x20 [ 1036.797734] [] cpu_startup_entry+0x2b7/0x3a0 [ 1036.804641] [] start_secondary+0x15c/0x1a0
Re: [PATCH] make __section_nr more efficient
On 2016/7/21 5:36, Dave Hansen wrote: On 07/19/2016 09:18 PM, Zhou Chengming wrote: When CONFIG_SPARSEMEM_EXTREME is disabled, __section_nr can get the section number with a subtraction directly. Does this actually *do* anything? It was a long time ago, but if I remember correctly, the entire loop in __section_nr() goes away because root_nr==NR_SECTION_ROOTS, so root_nr=1, and the compiler optimizes away the entire subtraction. So this basically adds an #ifdef and gets us nothing, although it makes the situation much more explicit. Perhaps the comment should say that this works *and* is efficient because the compiler can optimize all the extreme complexity away. . Thanks for your reply. I don't know the compiler will optimize the loop. But when I see the assembly code of __section_nr, it seems to still have the loop in it. My gcc version: gcc version 4.9.0 (GCC) CONFIG_SPARSEMEM_EXTREME: disabled Before this patch: <__section_nr>: 0: 55 push %rbp 1: 48 c7 c2 00 00 00 00mov$0x0,%rdx 4: R_X86_64_32S mem_section 8: 31 c0 xor%eax,%eax a: 48 89 e5mov%rsp,%rbp d: eb 0d jmp1c <__section_nr+0x1c> f: 48 83 c0 01 add$0x1,%rax 13: 48 81 fa 00 00 00 00cmp$0x0,%rdx 16: R_X86_64_32Smem_section+0x80 1a: 74 26 je 42 <__section_nr+0x42> 1c: 48 89 d1mov%rdx,%rcx 1f: ba 10 00 00 00 mov$0x10,%edx 24: 48 85 c9test %rcx,%rcx 27: 74 e6 je f <__section_nr+0xf> 29: 48 39 cfcmp%rcx,%rdi 2c: 48 8d 51 10 lea0x10(%rcx),%rdx 30: 72 dd jb f <__section_nr+0xf> 32: 48 39 d7cmp%rdx,%rdi 35: 73 d8 jaef <__section_nr+0xf> 37: 48 29 cfsub%rcx,%rdi 3a: 48 c1 ff 04 sar$0x4,%rdi 3e: 01 f8 add%edi,%eax 40: 5d pop%rbp 41: c3 retq 42: 48 29 cfsub%rcx,%rdi 45: b8 00 00 08 00 mov$0x8,%eax 4a: 48 c1 ff 04 sar$0x4,%rdi 4e: 01 f8 add%edi,%eax 50: 5d pop%rbp 51: c3 retq 52: 66 66 66 66 66 2e 0fdata32 data32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 59: 1f 84 00 00 00 00 00 After this patch: <__section_nr>: 0: 55 push %rbp 1: 48 89 f8mov%rdi,%rax 4: 48 2d 00 00 00 00 sub$0x0,%rax 6: R_X86_64_32S mem_section a: 48 89 e5mov%rsp,%rbp d: 48 c1 f8 04 sar$0x4,%rax 11: 5d pop%rbp 12: c3 retq 13: 66 66 66 66 2e 0f 1fdata32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 1a: 84 00 00 00 00 00 Thanks!
[PATCH v2 1/3] pmem: clarify a debug print in pmem_clear_poison
Prefix the sector number being cleared with a '0x' to make it clear that
this is a hex value.
Signed-off-by: Vishal Verma
---
drivers/nvdimm/pmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 608fc44..08ac2cb 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -57,7 +57,7 @@ static void pmem_clear_poison(struct pmem_device *pmem,
phys_addr_t offset,
cleared = nvdimm_clear_poison(dev, pmem->phys_addr + offset, len);
if (cleared > 0 && cleared / 512) {
- dev_dbg(dev, "%s: %llx clear %ld sector%s\n",
+ dev_dbg(dev, "%s: %#llx clear %ld sector%s\n",
__func__, (unsigned long long) sector,
cleared / 512, cleared / 512 > 1 ? "s" : "");
badblocks_clear(&pmem->bb, sector, cleared / 512);
--
2.7.4
[PATCH v2 2/3] nfit, libnvdimm: allow an ARS scrub to be triggered on demand
Normally, an ARS (Address Range Scrub) only happens at
boot/initialization time. There can however arise situations where a
bus-wide rescan is needed - notably, in the case of discovering a latent
media error, we should do a full rescan to figure out what other sectors
are bad, and thus potentially avoid triggering an mce on them in the
future. Also provide a sysfs trigger to start a bus-wide scrub.
Cc: Dan Williams
Cc: Rafael J. Wysocki
Cc:
Cc:
Signed-off-by: Vishal Verma
---
drivers/acpi/nfit.c | 123 +--
drivers/acpi/nfit.h | 4 +-
drivers/nvdimm/core.c| 7 +++
include/linux/libnvdimm.h| 1 +
tools/testing/nvdimm/test/nfit.c | 16 +
5 files changed, 131 insertions(+), 20 deletions(-)
diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
index ac6ddcc0..4e65255 100644
--- a/drivers/acpi/nfit.c
+++ b/drivers/acpi/nfit.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -806,8 +807,41 @@ static ssize_t revision_show(struct device *dev,
}
static DEVICE_ATTR_RO(revision);
+/*
+ * This shows the number of full Address Range Scrubs that have been
+ * completed since driver load time. Userspace can wait on this using
+ * select/poll etc.
+ */
+static ssize_t scrub_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct nvdimm_bus *nvdimm_bus = to_nvdimm_bus(dev);
+ struct nvdimm_bus_descriptor *nd_desc = to_nd_desc(nvdimm_bus);
+ struct acpi_nfit_desc *acpi_desc = to_acpi_desc(nd_desc);
+
+ return sprintf(buf, "%d\n", acpi_desc->scrub_count);
+}
+
+static int acpi_nfit_ars_rescan(struct acpi_nfit_desc *acpi_desc);
+
+static ssize_t scrub_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct nvdimm_bus *nvdimm_bus = to_nvdimm_bus(dev);
+ struct nvdimm_bus_descriptor *nd_desc = to_nd_desc(nvdimm_bus);
+ struct acpi_nfit_desc *acpi_desc = to_acpi_desc(nd_desc);
+ int rc;
+
+ rc = acpi_nfit_ars_rescan(acpi_desc);
+ if (rc)
+ return rc;
+ return size;
+}
+static DEVICE_ATTR_RW(scrub);
+
static struct attribute *acpi_nfit_attributes[] = {
&dev_attr_revision.attr,
+ &dev_attr_scrub.attr,
NULL,
};
@@ -2138,7 +2172,7 @@ static void acpi_nfit_async_scrub(struct acpi_nfit_desc
*acpi_desc,
unsigned int tmo = scrub_timeout;
int rc;
- if (nfit_spa->ars_done || !nfit_spa->nd_region)
+ if (!(nfit_spa->ars_required && nfit_spa->nd_region))
return;
rc = ars_start(acpi_desc, nfit_spa);
@@ -2227,7 +2261,9 @@ static void acpi_nfit_scrub(struct work_struct *work)
* firmware initiated scrubs to complete and then we go search for the
* affected spa regions to mark them scanned. In the second phase we
* initiate a directed scrub for every range that was not scrubbed in
-* phase 1.
+* phase 1. If we're called for a 'rescan', we harmlessly pass through
+* the first phase, but really only care about running phase 2, where
+* regions can be notified of new poison.
*/
/* process platform firmware initiated scrubs */
@@ -2330,14 +2366,17 @@ static void acpi_nfit_scrub(struct work_struct *work)
* Flag all the ranges that still need scrubbing, but
* register them now to make data available.
*/
- if (nfit_spa->nd_region)
- nfit_spa->ars_done = 1;
- else
+ if (!nfit_spa->nd_region) {
+ nfit_spa->ars_required = 1;
acpi_nfit_register_region(acpi_desc, nfit_spa);
+ }
}
list_for_each_entry(nfit_spa, &acpi_desc->spas, list)
acpi_nfit_async_scrub(acpi_desc, nfit_spa);
+ acpi_desc->scrub_count++;
+ if (acpi_desc->scrub_count_state)
+ sysfs_notify_dirent(acpi_desc->scrub_count_state);
mutex_unlock(&acpi_desc->init_mutex);
}
@@ -2495,6 +2534,27 @@ static int acpi_nfit_clear_to_send(struct
nvdimm_bus_descriptor *nd_desc,
return 0;
}
+static int acpi_nfit_ars_rescan(struct acpi_nfit_desc *acpi_desc)
+{
+ struct device *dev = acpi_desc->dev;
+ struct nfit_spa *nfit_spa;
+
+ if (work_busy(&acpi_desc->work))
+ return -EBUSY;
+
+ list_for_each_entry(nfit_spa, &acpi_desc->spas, list) {
+ struct acpi_nfit_system_address *spa = nfit_spa->spa;
+
+ if (nfit_spa_type(spa) != NFIT_SPA_PM)
+ continue;
+
+ nfit_spa->ars_required = 1;
+ }
+ queue_work(nfit_wq, &acpi_desc->work);
+ dev_info(dev, "%s: ars_scan triggered\n", __func__);
+ return 0;
+}
+
void acpi_nfit_desc_init(struct acpi_nfit_desc *acpi_desc
[PATCH v2 3/3] nfit: do an ARS scrub on hitting a latent media error
When a latent (unknown to 'badblocks') error is encountered, it will
trigger a machine check exception. On a system with machine check
recovery, this will only SIGBUS the process(es) which had the bad page
mapped (as opposed to a kernel panic on platforms without machine
check recovery features). In the former case, we want to trigger a full
rescan of that nvdimm bus. This will allow any additional, new errors
to be captured in the block devices' badblocks lists, and offending
operations on them can be trapped early, avoiding machine checks.
This is done by registering a callback function with the
x86_mce_decoder_chain and calling the new ars_rescan functionality with
the address in the mce notificatiion.
Cc: Dan Williams
Cc: Rafael J. Wysocki
Cc: Tony Luck
Cc:
Cc:
Signed-off-by: Vishal Verma
---
drivers/acpi/nfit.c | 89 +
drivers/acpi/nfit.h | 1 +
2 files changed, 90 insertions(+)
diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
index 4e65255..c9f1ee4 100644
--- a/drivers/acpi/nfit.c
+++ b/drivers/acpi/nfit.c
@@ -12,6 +12,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -24,6 +25,7 @@
#include
#include
#include
+#include
#include "nfit.h"
/*
@@ -51,6 +53,9 @@ module_param(disable_vendor_specific, bool, S_IRUGO);
MODULE_PARM_DESC(disable_vendor_specific,
"Limit commands to the publicly specified set\n");
+static LIST_HEAD(acpi_descs);
+static DEFINE_MUTEX(acpi_desc_lock);
+
static struct workqueue_struct *nfit_wq;
struct nfit_table_prev {
@@ -2416,9 +2421,11 @@ static int acpi_nfit_check_deletions(struct
acpi_nfit_desc *acpi_desc,
int acpi_nfit_init(struct acpi_nfit_desc *acpi_desc, acpi_size sz)
{
+ struct acpi_nfit_desc *acpi_desc_entry;
struct device *dev = acpi_desc->dev;
struct nfit_table_prev prev;
const void *end;
+ int found = 0;
u8 *data;
int rc;
@@ -2473,6 +2480,19 @@ int acpi_nfit_init(struct acpi_nfit_desc *acpi_desc,
acpi_size sz)
rc = acpi_nfit_register_regions(acpi_desc);
+ /*
+* We may get here due to an update of the nfit via _FIT.
+* Check if the acpi_desc we're (re)initializing is already
+* present in the list, and if so, don't re-add it
+*/
+ mutex_lock(&acpi_desc_lock);
+ list_for_each_entry(acpi_desc_entry, &acpi_descs, list)
+ if (acpi_desc_entry == acpi_desc)
+ found = 1;
+ if (found == 0)
+ list_add_tail(&acpi_desc->list, &acpi_descs);
+ mutex_unlock(&acpi_desc_lock);
+
out_unlock:
mutex_unlock(&acpi_desc->init_mutex);
return rc;
@@ -2555,6 +2575,65 @@ static int acpi_nfit_ars_rescan(struct acpi_nfit_desc
*acpi_desc)
return 0;
}
+static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
+ void *data)
+{
+ struct mce *mce = (struct mce *)data;
+ struct acpi_nfit_desc *acpi_desc;
+ struct nfit_spa *nfit_spa;
+
+ /* We only care about memory errors */
+ if (!(mce->status & MCACOD))
+ return NOTIFY_DONE;
+
+ /*
+* mce->addr contains the physical addr accessed that caused the
+* machine check. We need to walk through the list of NFITs, and see
+* if any of them matches that address, and only then start a scrub.
+*/
+ mutex_lock(&acpi_desc_lock);
+ list_for_each_entry(acpi_desc, &acpi_descs, list) {
+ struct device *dev = acpi_desc->dev;
+ int found_match = 0;
+
+ list_for_each_entry(nfit_spa, &acpi_desc->spas, list) {
+ struct acpi_nfit_system_address *spa = nfit_spa->spa;
+
+ if (nfit_spa_type(spa) != NFIT_SPA_PM)
+ continue;
+ /* find the spa that covers the mce addr */
+ if (spa->address > mce->addr)
+ continue;
+ if ((spa->address + spa->length - 1) < mce->addr)
+ continue;
+ found_match = 1;
+ dev_dbg(dev, "%s: addr in SPA %d (0x%llx, 0x%llx)\n",
+ __func__, spa->range_index, spa->address,
+ spa->length);
+ /*
+* We can break at the first match because we're going
+* to rescan all the SPA ranges. There shouldn't be any
+* aliasing anyway.
+*/
+ break;
+ }
+
+ /*
+* We can ignore an -EBUSY here because if an ARS is already
+* in progress, just let that be the last authoritative one
+*/
+ if (found_match)
+ acpi_nfit_ars_resc
[PATCH v2 0/3] ARS rescanning triggered by latent errors or userspace
Changes in v2: - Rework the ars_done flag in nfit_spa to be ars_required, and reuse it for rescanning (Dan) - Rename the ars_rescan attribute to simply 'scrub', and move into the nfit group since only nfit buses have this capability (Dan) - Make the scrub attribute RW, and on reads return the number of times a scrub has happened since driver load. This prompted some additional refactoring, notably the new helpers acpi_nfit_desc_alloc_register, and to_nvdimm_bus_dev. These are all in patch 2. (Dan) - Remove some redundant list_empty checks in patch 3 (Dan) - If the acpi_descs lists is not empty at driver unload time, WARN() (Dan) This series adds on-demand ARS scanning on both, discovery of latent media errors, and a sysfs trigger from userspace. The rescanning part is easy to test using the nfit_test framework - create a namespace (this will by default have bad sectors in the middle), clear the bad sectors by writing to them, trigger the rescan through sysfs, and the bad sectors will reappear in /sys/block//badblocks. For the mce handling, I've tested the notifier chain callback being called with a mock struct mce (called via another sysfs trigger - this isn't included in the patch obviously), which has the address field set to a known address in a SPA range, and the status field with the MCACOD flag set. What I haven't easily been able to test is the same callback path with a 'real world' mce, being called as part of the x86_mce_decoder_chain notifier. I'd therefore appreciate a closer look at the initial filtering done in nfit_handle_mce (patch 3/3) from Tony or anyone more familiar with mce handling. The series is based on v4.7-rc7, and a tree is available at https://git.kernel.org/cgit/linux/kernel/git/vishal/nvdimm.git/log/?h=ars-ondemand Vishal Verma (3): pmem: clarify a debug print in pmem_clear_poison nfit, libnvdimm: allow an ARS scrub to be triggered on demand nfit: do an ARS scrub on hitting a latent media error drivers/acpi/nfit.c | 214 +++ drivers/acpi/nfit.h | 5 +- drivers/nvdimm/core.c| 7 ++ drivers/nvdimm/pmem.c| 2 +- include/linux/libnvdimm.h| 1 + tools/testing/nvdimm/test/nfit.c | 16 +++ 6 files changed, 224 insertions(+), 21 deletions(-) -- 2.7.4
Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists
On Wed, Jul 20, 2016 at 07:48:13PM -0500, Christoph Lameter wrote: > On Wed, 20 Jul 2016, Waiman Long wrote: > > > Christoph, are you OK with Tejun's request to revert the name back to > > percpu_list? Or do you still think the current name is better? > > The percpu structure contains a spinlock and may be remotely accessed? You > are aware that other percpu variables that share the same cacheline will > be negatively impacted by accesses from other processors? > > The role of percpu areas are to have memory areas where the code can > expect that cachelines are exclusively there for that processor. > > How frequent are the remote accesses? If this is rare then ok. Remote access will be the common case on traversal and removal from the superblock inode list. Under memory reclaim, the access should at least be from a CPU on the same node (as inode reclaim is NUMA aware). However, any other inode eviction event (e.g. inode unlink) removing it from the sb list will essentially be from a random CPU. Traversals (such as from the sync code, or cache invalidations) will run on a single CPU, so alomst all access from them will be be remote. So it's really only a per-cpu structure for list addition Cheers, Dave. -- Dave Chinner da...@fromorbit.com
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
between commit:
ec25bc04ed8e ("net/mlx4_en: Add resilience in low memory systems")
from the net tree and commit:
9ecc2d86171a ("net/mlx4_en: add xdp forwarding and data write support")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 44cf16d01f42,f32e272c83dd..
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@@ -1730,28 -1722,32 +1729,35 @@@ static int mlx4_en_set_channels(struct
!channel->tx_count || !channel->rx_count)
return -EINVAL;
+ if (channel->tx_count * MLX4_EN_NUM_UP <= priv->xdp_ring_num) {
+ en_err(priv, "Minimum %d tx channels required with XDP on\n",
+ priv->xdp_ring_num / MLX4_EN_NUM_UP + 1);
+ return -EINVAL;
+ }
+
+ tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
mutex_lock(&mdev->state_lock);
+ memcpy(&new_prof, priv->prof, sizeof(struct mlx4_en_port_profile));
+ new_prof.num_tx_rings_p_up = channel->tx_count;
+ new_prof.tx_ring_num = channel->tx_count * MLX4_EN_NUM_UP;
+ new_prof.rx_ring_num = channel->rx_count;
+
+ err = mlx4_en_try_alloc_resources(priv, tmp, &new_prof);
+ if (err)
+ goto out;
+
if (priv->port_up) {
port_up = 1;
mlx4_en_stop_port(dev, 1);
}
- mlx4_en_free_resources(priv);
-
- priv->num_tx_rings_p_up = channel->tx_count;
- priv->tx_ring_num = channel->tx_count * MLX4_EN_NUM_UP;
- priv->rx_ring_num = channel->rx_count;
-
- err = mlx4_en_alloc_resources(priv);
- if (err) {
- en_err(priv, "Failed reallocating port resources\n");
- goto out;
- }
+ mlx4_en_safe_replace_resources(priv, tmp);
- netif_set_real_num_tx_queues(dev, priv->tx_ring_num);
+ netif_set_real_num_tx_queues(dev, priv->tx_ring_num -
+ priv->xdp_ring_num);
netif_set_real_num_rx_queues(dev, priv->rx_ring_num);
if (dev->num_tc)
Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists
On 07/20/2016 08:48 PM, Christoph Lameter wrote: On Wed, 20 Jul 2016, Waiman Long wrote: Christoph, are you OK with Tejun's request to revert the name back to percpu_list? Or do you still think the current name is better? The percpu structure contains a spinlock and may be remotely accessed? You are aware that other percpu variables that share the same cacheline will be negatively impacted by accesses from other processors? The spinlock can be remotely accessed during deletion as well as the iteration of all the percpu lists. Iteration of all the percpu data is not a new thing as it may also be done in percpu_counter when calling percpu_counter_sum(). Yes, remote access can have a negative performance impact on the access of other percpu data that happen to reside in the same cacheline. The role of percpu areas are to have memory areas where the code can expect that cachelines are exclusively there for that processor. How frequent are the remote accesses? If this is rare then ok. I can't say how often that will happen for the dlock list. If the thread that create the inodes does not migrate to other CPU, the deletion of the inode should also happens in the same CPU. One way to reduce the performance impact is to make the percpu head structure cacheline aligned at the expense of some wasted space. I could add an additional parameter to alloc_dlock_list_head() to force cacheline alignment if the caller wish to do so. What do think about that? Cheers, Longman
Re: linux-next: manual merge of the xfs tree with Linus' tree
On Thu, Jul 21, 2016 at 11:07:56AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xfs tree got a conflict in:
>
> fs/xfs/xfs_ioctl.c
>
> between commit:
>
> 3e0a39654645 ("xfs: fix type confusion in xfs_ioc_swapext")
>
> from Linus' tree and commit:
>
> 7f1b62457b58 ("xfs: fix type confusion in xfs_ioc_swapext")
>
> from the xfs tree.
>
> These are not quite the same patch :-(
Yeah, I added comments to explain the code, because it's not obvious
why the check was added, and I couldn't find any other examples of
such checks in fs/. So, in five years time when I look at that code
again, the comment will remind me why it's a bad idea to remove what
appears to be an unnecesary check...
> I fixed it up (I used the version in the xfs tree) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging.
Yup, I planned to let Linus know. Patches in private emails that
aren't tagged [PATCH] in the subject line don't get the immediate
attention of my mail filters, so I didn't see it immediately.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
[PATCH] x86/ebda: If the EBDA is in lowmem, reserve only 4k for the EBDA
Under some conditions, my Dell XPS 13 9350 puts the EBDA at 0x2c000 but reports the lowmem cutoff as 0. The old code reserves everything above 0x2c000 and I can't boot [1]. Due to an old quirk, we assume that lowmem ends at 0x9f000. Nonetheless, the old code would reserve everything from 0x2c000 to 0xf. Be a little less conservative: when the EBDA is in lowmem, reserve 4k the EBDA and reserve highmem separately. On my laptop, this ends up being more or less a no-op: the EBDA shows up as a single-page of runtime data in the EFI memmap. Go Dell for getting this right. [1] This only breaks boot in practice when some other firmware or GRUB oddity that I don't fully understand kicks in causing the memory below 0x2c000 to be unusable. Signed-off-by: Andy Lutomirski --- This is intentionally not tagged for -stable. I think it's -stable material *eventually*, but the problem that's fixed is not widespread (it's apparently just me for now) and there's plenty of potential to regress something that was worked around by the old code. arch/x86/kernel/ebda.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/ebda.c b/arch/x86/kernel/ebda.c index afe65dffee80..2183a7eac646 100644 --- a/arch/x86/kernel/ebda.c +++ b/arch/x86/kernel/ebda.c @@ -62,10 +62,12 @@ void __init reserve_ebda_region(void) if (lowmem < INSANE_CUTOFF) lowmem = LOWMEM_CAP; - /* Use the lower of the lowmem and EBDA markers as the cutoff */ - lowmem = min(lowmem, ebda_addr); lowmem = min(lowmem, LOWMEM_CAP); /* Absolute cap */ /* reserve all memory between lowmem and the 1MB mark */ memblock_reserve(lowmem, 0x10 - lowmem); + + /* if the EBDA is in lowmem, reserve it separately. */ + if (ebda_addr < lowmem) + memblock_reserve(ebda_addr, 4096); } -- 2.7.4
Re: [PATCH] kconfig: tinyconfig: provide whole choice blocks to avoid warnings
Hi Arnd, 2016-07-19 1:00 GMT+09:00 Arnd Bergmann : > Using "make tinyconfig" produces a couple of annoying warnings that show up > for build test machines all the time: > > .config:966:warning: override: NOHIGHMEM changes choice state > .config:965:warning: override: SLOB changes choice state > .config:963:warning: override: KERNEL_XZ changes choice state > .config:962:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > .config:933:warning: override: SLOB changes choice state > .config:930:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > .config:870:warning: override: SLOB changes choice state > .config:868:warning: override: KERNEL_XZ changes choice state > .config:867:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > > I've made a previous attempt at fixing them and we discussed a number of > alternatives. > > I tried changing the Makefile to use "merge_config.sh -n $(fragment-list)" > but couldn't get that to work properly. > > This is yet another approach, based on the observation that we do want > to see a warning for conflicting 'choice' options, and that we can simply > make them non-conflicting by listing all other options as disabled. > This is a trivial patch that we can apply independent of plans for other > changes. > > Signed-off-by: Arnd Bergmann > Link: https://storage.kernelci.org/mainline/v4.7-rc6/x86-tinyconfig/build.log > https://patchwork.kernel.org/patch/9212749/ > --- > kernel/configs/tiny.config | 8 > 1 file changed, 8 insertions(+) > > diff --git a/kernel/configs/tiny.config b/kernel/configs/tiny.config > index c2de56ab0fce..3eeade4d876d 100644 > --- a/kernel/configs/tiny.config > +++ b/kernel/configs/tiny.config > @@ -1,4 +1,12 @@ > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > +# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set > CONFIG_KERNEL_XZ=y > +# CONFIG_KERNEL_GZIP is not set > +# CONFIG_KERNEL_BZIP2 is not set > +# CONFIG_KERNEL_LZMA is not set > +# CONFIG_KERNEL_LZO is not set > +# CONFIG_KERNEL_LZ4 is not set > CONFIG_OPTIMIZE_INLINING=y > +# CONFIG_SLUB is not set > +# CONFIG_SLAB is not set > CONFIG_SLOB=y Which sorting policy are you using here? I prefer the same order as they appear in the .config file. Like this. +# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y +# CONFIG_KERNEL_GZIP is not set +# CONFIG_KERNEL_BZIP2 is not set +# CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y +# CONFIG_KERNEL_LZO is not set +# CONFIG_KERNEL_LZ4 is not set CONFIG_OPTIMIZE_INLINING=y +# CONFIG_SLAB is not set +# CONFIG_SLUB is not set CONFIG_SLOB=y -- Best Regards Masahiro Yamada
[PATCH v7 5/7] perf config: Initialize ui_browser__colorsets with default config items
Set default config values for 'colors' section with 'colors_config_items[]'
instead of actual const char * type values.
(e.g. using colors_config_item[CONFIG_COLORS_TOP].value.s
instead of "red, default" string value for 'colors.top')
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Wang Nan
Cc: Alexander Shishkin
Signed-off-by: Taeung Song
---
tools/perf/ui/browser.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 31e2028..598f434 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -509,37 +509,30 @@ static struct ui_browser_colorset {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
- .colors = "red, default",
},
{
.colorset = HE_COLORSET_MEDIUM,
.name = "medium",
- .colors = "green, default",
},
{
.colorset = HE_COLORSET_NORMAL,
.name = "normal",
- .colors = "default, default",
},
{
.colorset = HE_COLORSET_SELECTED,
.name = "selected",
- .colors = "black, yellow",
},
{
.colorset = HE_COLORSET_JUMP_ARROWS,
.name = "jump_arrows",
- .colors = "blue, default",
},
{
.colorset = HE_COLORSET_ADDR,
.name = "addr",
- .colors = "magenta, default",
},
{
.colorset = HE_COLORSET_ROOT,
.name = "root",
- .colors = "white, blue",
},
{
.name = NULL,
@@ -724,10 +717,28 @@ void __ui_browser__line_arrow(struct ui_browser *browser,
unsigned int column,
__ui_browser__line_arrow_down(browser, column, start, end);
}
+static void default_colors_config_init(void)
+{
+ int i, j;
+
+ for (i = 0; ui_browser__colorsets[i].name != NULL; ++i) {
+ const char *name = ui_browser__colorsets[i].name;
+
+ for (j = 0; colors_config_items[j].name != NULL; j++) {
+ if (!strcmp(name, colors_config_items[j].name)) {
+ ui_browser__colorsets[i].colors =
+ colors_config_items[j].value.s;
+ break;
+ }
+ }
+ }
+}
+
void ui_browser__init(void)
{
int i = 0;
+ default_colors_config_init();
perf_config(ui_browser__color_config, NULL);
while (ui_browser__colorsets[i].name) {
--
2.5.0
[PATCH v7 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color
To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
also have only one value like 'default_config_item' type.
If we use combined {fore,back}ground colors values in ui_browser_colorset,
it smoothly work to initialize default config values for 'colors' config
by 'colors_config_items' array that contains default values for it at
util/config.c.
because both actual variable and config item of 'colors_config_items'
are equal in the number of values (as just one).
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Wang Nan
Cc: Alexander Shishkin
Signed-off-by: Taeung Song
---
tools/perf/ui/browser.c | 53 +++--
1 file changed, 25 insertions(+), 28 deletions(-)
diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
index 3eb3edb..31e2028 100644
--- a/tools/perf/ui/browser.c
+++ b/tools/perf/ui/browser.c
@@ -503,61 +503,53 @@ unsigned int ui_browser__list_head_refresh(struct
ui_browser *browser)
}
static struct ui_browser_colorset {
- const char *name, *fg, *bg;
+ const char *name, *colors;
int colorset;
} ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
- .fg = "red",
- .bg = "default",
+ .colors = "red, default",
},
{
.colorset = HE_COLORSET_MEDIUM,
.name = "medium",
- .fg = "green",
- .bg = "default",
+ .colors = "green, default",
},
{
.colorset = HE_COLORSET_NORMAL,
.name = "normal",
- .fg = "default",
- .bg = "default",
+ .colors = "default, default",
},
{
.colorset = HE_COLORSET_SELECTED,
.name = "selected",
- .fg = "black",
- .bg = "yellow",
+ .colors = "black, yellow",
},
{
.colorset = HE_COLORSET_JUMP_ARROWS,
.name = "jump_arrows",
- .fg = "blue",
- .bg = "default",
+ .colors = "blue, default",
},
{
.colorset = HE_COLORSET_ADDR,
.name = "addr",
- .fg = "magenta",
- .bg = "default",
+ .colors = "magenta, default",
},
{
.colorset = HE_COLORSET_ROOT,
.name = "root",
- .fg = "white",
- .bg = "blue",
+ .colors = "white, blue",
},
{
.name = NULL,
}
};
-
static int ui_browser__color_config(const char *var, const char *value,
void *data __maybe_unused)
{
- char *fg = NULL, *bg;
+ char *colors;
int i;
/* same dir for all commands */
@@ -570,22 +562,18 @@ static int ui_browser__color_config(const char *var,
const char *value,
if (strcmp(ui_browser__colorsets[i].name, name) != 0)
continue;
- fg = strdup(value);
- if (fg == NULL)
- break;
+ if (strstr(value, ",") == NULL)
+ return -1;
- bg = strchr(fg, ',');
- if (bg == NULL)
+ colors = strdup(value);
+ if (colors == NULL)
break;
+ ui_browser__colorsets[i].colors = colors;
- *bg = '\0';
- while (isspace(*++bg));
- ui_browser__colorsets[i].bg = bg;
- ui_browser__colorsets[i].fg = fg;
return 0;
}
- free(fg);
+ free(colors);
return -1;
}
@@ -743,8 +731,17 @@ void ui_browser__init(void)
perf_config(ui_browser__color_config, NULL);
while (ui_browser__colorsets[i].name) {
+ char *colors, *fg, *bg;
struct ui_browser_colorset *c = &ui_browser__colorsets[i++];
- sltt_set_color(c->colorset, c->name, c->fg, c->bg);
+
+ colors = strdup(c->colors);
+ if (fg == NULL)
+ break;
+ fg = strtok(colors, ",");
+ bg = strtok(NULL, ",");
+ bg = ltrim(bg);
+ sltt_set_color(c->colorset, c->name, fg, bg);
+ free(colors);
}
annotate_browser__init();
--
2.5.0
[PATCH v7 7/7] perf config: Initialize annotate_browser__opts with default config items
Set default config values for 'annotate' section with 'annotate_config_items[]'
instead of actual bool type values.
(e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value.b
instead of 'true' bool type value for 'annotate.use_offset'.)
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Wang Nan
Cc: Alexander Shishkin
Signed-off-by: Taeung Song
---
tools/perf/ui/browsers/annotate.c | 16
tools/perf/util/config.h | 3 +++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index 29dc6d2..7ab9875 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -38,10 +38,7 @@ static struct annotate_browser_opt {
show_linenr,
show_nr_jumps,
show_total_period;
-} annotate_browser__opts = {
- .use_offset = true,
- .jump_arrows= true,
-};
+} annotate_browser__opts;
struct annotate_browser {
struct ui_browser b;
@@ -1157,7 +1154,18 @@ static int annotate__config(const char *var, const char
*value,
return 0;
}
+static void default_annotate_config_init(void)
+{
+ annotate_browser__opts.hide_src_code = CONF_DEFAULT_BOOL(ANNOTATE,
HIDE_SRC_CODE);
+ annotate_browser__opts.use_offset = CONF_DEFAULT_BOOL(ANNOTATE,
USE_OFFSET);
+ annotate_browser__opts.jump_arrows = CONF_DEFAULT_BOOL(ANNOTATE,
JUMP_ARROWS);
+ annotate_browser__opts.show_linenr = CONF_DEFAULT_BOOL(ANNOTATE,
SHOW_LINENR);
+ annotate_browser__opts.show_nr_jumps = CONF_DEFAULT_BOOL(ANNOTATE,
SHOW_NR_JUMPS);
+ annotate_browser__opts.show_total_period = CONF_DEFAULT_BOOL(ANNOTATE,
SHOW_TOTAL_PERIOD);
+}
+
void annotate_browser__init(void)
{
+ default_annotate_config_init();
perf_config(annotate__config, NULL);
}
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 2fcfd51..76f5b21 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -136,6 +136,9 @@ struct default_config_section {
#define CONF_END() \
{ .name = NULL }
+#define CONF_DEFAULT_BOOL(sec, name) \
+ default_sections[CONFIG_##sec].items[CONFIG_##sec##_##name].value.b
+
extern const struct default_config_section default_sections[];
extern const struct default_config_item colors_config_items[];
extern const struct default_config_item annotate_config_items[];
--
2.5.0
[PATCH v5 1/2] Doc/memory-barriers: Fix a typo of example result
An example result for data dependent write has a typo. This commit fixes the wrong typo. Signed-off-by: SeongJae Park --- Documentation/memory-barriers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 19c8eb6..ba818ec 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -609,7 +609,7 @@ A data-dependency barrier must also order against dependent writes: The data-dependency barrier must order the read into Q with the store into *Q. This prohibits this outcome: - (Q == B) && (B == 4) + (Q == &B) && (B == 4) Please note that this pattern should be rare. After all, the whole point of dependency ordering is to -prevent- writes to the data structure, along -- 1.9.1
[PATCH v5 0/2] Doc/memory-barriers: Add Korean translation
This patchset adds a Korean translation of memory-barriers.txt and fix a typo that was found during the translation. The translation has started from Feb, 2016 and using a public git tree[1] to manage the work. It's commit history says that it is following upstream changes as well. Changes from v4: - Polish readability for overall text again: `1 file changed, 838 insertions(+), 799 deletions(-)` Changes from v3: - Polish readability for overall text: `1 file changed, 533 insertions(+), 505 deletions(-)` - Add disclaimer of translation [1] https://github.com/sjp38/linux.doc_trans_membarrier SeongJae Park (2): Doc/memory-barriers: Fix a typo of example result Doc/memory-barriers: Add Korean translation Documentation/ko_KR/memory-barriers.txt | 3134 +++ Documentation/memory-barriers.txt |2 +- 2 files changed, 3135 insertions(+), 1 deletion(-) create mode 100644 Documentation/ko_KR/memory-barriers.txt -- 1.9.1
Re: [PATCH 07/12] syscon: dt-bindings: Add documentation for Aspeed system control units
On Wed, 2016-07-20 at 14:09 -0500, Rob Herring wrote: > On Wed, Jul 20, 2016 at 03:28:28PM +0930, Andrew Jeffery wrote: > > > > Signed-off-by: Andrew Jeffery > > --- > > Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 16 > > 1 file changed, 16 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-scu.txt > > > > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt > > b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt > > new file mode 100644 > > index ..4df798799101 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt > > @@ -0,0 +1,16 @@ > > +The Aspeed System Control Unit manages the global behaviour of the SoC, > > +configuring elements such as clocks, pinmux, and reset. > > + > > +Required properties: > > +- compatible: One of: > > + "aspeed,g4-scu", "syscon", "simple-mfd" > > + "aspeed,g5-scu", "syscon", "simple-mfd" > These (and the pinctrl probably) really need SoC specific compatible > strings. You can keep these as fallbacks though. These are the parts of > SoCs that really vary chip to chip. I'll add the SoC-specific compatible strings. Cheers, Andrew signature.asc Description: This is a digitally signed message part
[PATCH v7 6/7] perf config: Add default section and item arrays for 'annotate' config
Actual variable for configs of 'annotate' section is like below.
(at ui/browsers/annoate.c)
static struct annotate_browser_opt {
bool hide_src_code,
use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
show_total_period;
} annotate_browser__opts = {
.use_offset = true,
.jump_arrows = true,
};
But I suggest using default config arrays for 'annotate' section that
contain all default config key-value pairs for it.
In near future, this arrays will be used on ui/browsers/annoate.c
because of setting default values of actual variables for 'annotate' config.
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Wang Nan
Cc: Alexander Shishkin
Signed-off-by: Taeung Song
---
tools/perf/util/config.c | 11 +++
tools/perf/util/config.h | 11 +++
2 files changed, 22 insertions(+)
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index a0c0170..d8d5415 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -41,8 +41,19 @@ const struct default_config_item colors_config_items[] = {
CONF_END()
};
+const struct default_config_item annotate_config_items[] = {
+ CONF_BOOL_VAR("hide_src_code", false),
+ CONF_BOOL_VAR("use_offset", true),
+ CONF_BOOL_VAR("jump_arrows", true),
+ CONF_BOOL_VAR("show_nr_jumps", false),
+ CONF_BOOL_VAR("show_linenr", false),
+ CONF_BOOL_VAR("show_total_period", false),
+ CONF_END()
+};
+
const struct default_config_section default_sections[] = {
{ .name = "colors", .items = colors_config_items },
+ { .name = "annotate", .items = annotate_config_items },
};
static int get_next_char(void)
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index b9190fe..2fcfd51 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -75,6 +75,7 @@ enum perf_config_type {
enum config_section_idx {
CONFIG_COLORS,
+ CONFIG_ANNOTATE,
};
enum colors_config_items_idx {
@@ -87,6 +88,15 @@ enum colors_config_items_idx {
CONFIG_COLORS_ROOT,
};
+enum annotate_config_items_idx {
+ CONFIG_ANNOTATE_HIDE_SRC_CODE,
+ CONFIG_ANNOTATE_USE_OFFSET,
+ CONFIG_ANNOTATE_JUMP_ARROWS,
+ CONFIG_ANNOTATE_SHOW_NR_JUMPS,
+ CONFIG_ANNOTATE_SHOW_LINENR,
+ CONFIG_ANNOTATE_SHOW_TOTAL_PERIOD,
+};
+
struct default_config_item {
const char *name;
union {
@@ -128,5 +138,6 @@ struct default_config_section {
extern const struct default_config_section default_sections[];
extern const struct default_config_item colors_config_items[];
+extern const struct default_config_item annotate_config_items[];
#endif /* __PERF_CONFIG_H */
--
2.5.0
[PATCH v7 2/7] perf config: Add macros assigning key-value pairs to default_config_item
In near future, default_config_item arrays will be added
(e.g. const struct default_config_item colors_config_items[])
To simply assign config key-value pairs to default_config_item,
add macros that are CONF_VAR() and CONF_*_VAR() for each type.
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Wang Nan
Cc: Masami Hiramatsu
Cc: Alexander Shishkin
Signed-off-by: Taeung Song
---
tools/perf/util/config.h | 20
1 file changed, 20 insertions(+)
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 1fd8e4c..613900f 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -92,4 +92,24 @@ struct default_config_section {
const struct default_config_item *items;
};
+#define CONF_VAR(_name, _field, _val, _type) \
+ { .name = _name, .value._field = _val, .type = _type }
+
+#define CONF_BOOL_VAR(_name, _val) \
+ CONF_VAR(_name, b, _val, CONFIG_TYPE_BOOL)
+#define CONF_INT_VAR(_name, _val) \
+ CONF_VAR(_name, i, _val, CONFIG_TYPE_INT)
+#define CONF_LONG_VAR(_name, _val) \
+ CONF_VAR(_name, l, _val, CONFIG_TYPE_LONG)
+#define CONF_U64_VAR(_name, _val) \
+ CONF_VAR(_name, ll, _val, CONFIG_TYPE_U64)
+#define CONF_FLOAT_VAR(_name, _val)\
+ CONF_VAR(_name, f, _val, CONFIG_TYPE_FLOAT)
+#define CONF_DOUBLE_VAR(_name, _val) \
+ CONF_VAR(_name, d, _val, CONFIG_TYPE_DOUBLE)
+#define CONF_STR_VAR(_name, _val) \
+ CONF_VAR(_name, s, _val, CONFIG_TYPE_STRING)
+#define CONF_END() \
+ { .name = NULL }
+
#endif /* __PERF_CONFIG_H */
--
2.5.0
[PATCH v7 1/7] perf config: Introduce default_config_section and default_config_item for default config key-value pairs
When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
For example,
If there isn't user config value at ~/.perfconfig
for 'annotate.use_offset' config variable,
default value for it is 'true' bool type value in perf like below.
At ui/browsers/annoate.c
static struct annotate_browser_opt {
bool hide_src_code,
use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
show_total_period;
} annotate_browser__opts = {
.use_offset = true,
.jump_arrows = true,
};
But I suggest using 'struct default_config_section' and
'struct default_config_item' that can contain default config key-value pairs
in order to initialize default config values with them, in near future.
If we do, we could manage default perf config values at one spot (i.e.
util/config.c)
with default config arrays and it could be easy and simple to modify
existing default config values or add default values for new config item.
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Wang Nan
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Masami Hiramatsu
Cc: Alexander Shishkin
Signed-off-by: Taeung Song
---
tools/perf/util/config.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 6f813d4..1fd8e4c 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -63,4 +63,33 @@ void perf_config__refresh(void);
perf_config_sections__for_each_entry(&set->sections, section)
\
perf_config_items__for_each_entry(§ion->items, item)
+enum perf_config_type {
+ CONFIG_TYPE_BOOL,
+ CONFIG_TYPE_INT,
+ CONFIG_TYPE_LONG,
+ CONFIG_TYPE_U64,
+ CONFIG_TYPE_FLOAT,
+ CONFIG_TYPE_DOUBLE,
+ CONFIG_TYPE_STRING
+};
+
+struct default_config_item {
+ const char *name;
+ union {
+ bool b;
+ int i;
+ u32 l;
+ u64 ll;
+ float f;
+ double d;
+ const char *s;
+ } value;
+ enum perf_config_type type;
+};
+
+struct default_config_section {
+ const char *name;
+ const struct default_config_item *items;
+};
+
#endif /* __PERF_CONFIG_H */
--
2.5.0
[RFC PATCH v7 0/7] perf config: Introduce default config key-value pairs arrays
Hello, :)
When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
But I suggest using default config key-value pairs arrays.
For example,
If there isn't user config value at ~/.perfconfig for 'annotate.use_offset'
config variable,
default value for it is 'true' bool type value in perf like below.
At ui/browsers/annoate.c
static struct annotate_browser_opt {
bool hide_src_code,
use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
show_total_period;
} annotate_browser__opts = {
.use_offset = true,
.jump_arrows = true,
};
But if we use new config arrays that have all default config key-value pairs,
we could initialize default config values with them.
If we do, we can manage default perf config values at one spot (like
util/config.c)
and It can be easy and simple to modify existing default config values or
add default values for new config item.
For example,
If we use new default config arrays and there isn't user config value for
'annoate.use_offset'
default value for it will be set as
annotate_config_items[CONFIG_ANNOATE_USE_OFFSET].value.b
instead of actual boolean type value 'true'.
IMHO, I think it would needed to use new default config arrays
to manage default perf config values more effectively.
And this pathset contains patchs for only 'colors' and 'annoate' section
because waiting for other opinions.
If you review this patchset, I'd appreciate it :-)
Thanks,
Taeung
v7:
- rebased on current acme/perf/core
v6:
- rename 'fore_back_colors' to simple 'colors' of ui_browser_colorset (Namhyung)
- remove unnecssary whitespace changes of PATCH 4/7, 5/7 (Namhyung)
- make more general macro instead of making accessor macro for each config
section (Namhyung)
v5:
- rebased on current acme/perf/core
v4:
- rename 'fb_ground' to 'fore_back_colors' (Namhyung)
- add struct default_config_section
- split first patch[PATCH 1/7] as two
- remove perf_default_config_init() at perf.c
- rebased on current acme/perf/core
v3:
- remove default config arrays for the rest sections except 'colors' and
'annotate'
- use combined {fore, back}ground colors instead of each two color
- introduce perf_default_config_init() that call all default_*_config_init()
for each config section
v2:
- rename 'ui_browser__config_gcolors' to 'ui_browser__config_colors' (Arnaldo)
- change 'ground colors' to '{back, fore}ground colors' (Arnaldo)
- use strtok + ltrim instead of strchr and while (isspace(*++bg)); (Arnaldo)
Taeung Song (7):
perf config: Introduce default_config_section and default_config_item
for default config key-value pairs
perf config: Add macros assigning key-value pairs to
default_config_item
perf config: Add default section and item arrays for 'colors' config
perf config: Use combined {fore,back}ground colors value instead of
each two color
perf config: Initialize ui_browser__colorsets with default config
items
perf config: Add default section and item arrays for 'annotate' config
perf config: Initialize annotate_browser__opts with default config
items
tools/perf/ui/browser.c | 64 +--
tools/perf/ui/browsers/annotate.c | 16 ++--
tools/perf/util/config.c | 26 +
tools/perf/util/config.h | 80 +++
4 files changed, 154 insertions(+), 32 deletions(-)
--
2.5.0
[PATCH v7 3/7] perf config: Add default section and item arrays for 'colors' config
Actual variable for configs of 'colors' section is like below.
(at ui/browser.c)
static struct ui_browser_colorset {
const char *name, *fg, *bg;
int colorset;
} ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name = "top",
.fg = "red",
.bg = "default",
},
...
But I suggest using default config arrays for 'colors' section that
contain all default config key-value pairs for it.
In near future, this array will be used on ui/browser.c
because of setting default values of actual variables for 'colors' config.
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Wang Nan
Cc: Alexander Shishkin
Signed-off-by: Taeung Song
---
tools/perf/util/config.c | 15 +++
tools/perf/util/config.h | 17 +
2 files changed, 32 insertions(+)
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index 18dae74..a0c0170 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -30,6 +30,21 @@ static struct perf_config_set *config_set;
const char *config_exclusive_filename;
+const struct default_config_item colors_config_items[] = {
+ CONF_STR_VAR("top", "red, default"),
+ CONF_STR_VAR("medium", "green, default"),
+ CONF_STR_VAR("normal", "default, default"),
+ CONF_STR_VAR("selected", "black, yellow"),
+ CONF_STR_VAR("jump_arrows", "blue, default"),
+ CONF_STR_VAR("addr", "magenta, default"),
+ CONF_STR_VAR("root", "white, blue"),
+ CONF_END()
+};
+
+const struct default_config_section default_sections[] = {
+ { .name = "colors", .items = colors_config_items },
+};
+
static int get_next_char(void)
{
int c;
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 613900f..b9190fe 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -73,6 +73,20 @@ enum perf_config_type {
CONFIG_TYPE_STRING
};
+enum config_section_idx {
+ CONFIG_COLORS,
+};
+
+enum colors_config_items_idx {
+ CONFIG_COLORS_TOP,
+ CONFIG_COLORS_MEDIUM,
+ CONFIG_COLORS_NORMAL,
+ CONFIG_COLORS_SELECTED,
+ CONFIG_COLORS_JUMP_ARROWS,
+ CONFIG_COLORS_ADDR,
+ CONFIG_COLORS_ROOT,
+};
+
struct default_config_item {
const char *name;
union {
@@ -112,4 +126,7 @@ struct default_config_section {
#define CONF_END() \
{ .name = NULL }
+extern const struct default_config_section default_sections[];
+extern const struct default_config_item colors_config_items[];
+
#endif /* __PERF_CONFIG_H */
--
2.5.0
Re: [RFC 7/7] [media] rc: add support for IR LEDs driven through SPI
Hi Sean, > > + int ret; > > + struct ir_spi_data *idata = (struct ir_spi_data *) dev->priv; > > No cast needed. yes, thanks. > > + ret = regulator_enable(idata->regulator); > > + if (ret) > > + return ret; > > + > > + mutex_lock(&idata->mutex); > > + idata->xfer.len = n; > > + idata->xfer.tx_buf = buffer; > > + mutex_unlock(&idata->mutex); > > I'm not convinced the locking works here. You want to guard against > someone modifying xfer while you are sending (so in spi_sync_transfer), > which this locking is not doing. You could declare a > local "struct spi_transfer xfer" and avoid the mutex altogether. I cannot declare xfer locally because the spi framework needs a statically allocated xfer, so that either I dynamically allocate it in the function or I declare it global in idata. With the mutex I would like to prevent different tasks to change the value at the same time, it's an easy case, it shouldn't make much difference. There are checkpatch issues, in the next patchset I will fix them. Thanks a lot for your review, Andi
linux-next: manual merge of the xfs tree with Linus' tree
Hi all,
Today's linux-next merge of the xfs tree got a conflict in:
fs/xfs/xfs_ioctl.c
between commit:
3e0a39654645 ("xfs: fix type confusion in xfs_ioc_swapext")
from Linus' tree and commit:
7f1b62457b58 ("xfs: fix type confusion in xfs_ioc_swapext")
from the xfs tree.
These are not quite the same patch :-(
I fixed it up (I used the version in the xfs tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[PATCH v3 2/2] pstore/ram: Set pstore flags dynamically
The ramoops can be configured to enable each pstore type by setting
their size. In that case, it'd be better not to register disabled types
in the first place.
Signed-off-by: Namhyung Kim
---
fs/pstore/ram.c| 8 +++-
include/linux/pstore.h | 2 --
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index d08bfd611b11..80a4d44464fc 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -539,7 +539,13 @@ static int ramoops_probe(struct platform_device *pdev)
goto fail_clear;
}
- cxt->pstore.flags = PSTORE_FLAGS_ALL;
+ cxt->pstore.flags = PSTORE_FLAGS_DMESG;
+ if (ctx->console_size)
+ cxt->pstore.flags |= PSTORE_FLAGS_CONOLE;
+ if (ctx->ftrace_size)
+ cxt->pstore.flags |= PSTORE_FLAGS_FTRACE;
+ if (ctx->pmsg_size)
+ cxt->pstore.flags |= PSTORE_FLAGS_PMSG;
err = pstore_register(&cxt->pstore);
if (err) {
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 3ba0c1af40e5..a6d80bd960cb 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -78,8 +78,6 @@ struct pstore_info {
#define PSTORE_FLAGS_FTRACE(1 << 2)
#define PSTORE_FLAGS_PMSG (1 << 3)
-#define PSTORE_FLAGS_ALL ((1 << 4) - 1)
-
extern int pstore_register(struct pstore_info *);
extern void pstore_unregister(struct pstore_info *);
extern bool pstore_cannot_block_path(enum kmsg_dump_reason reason);
--
2.8.0
[PATCH v3 1/2] pstore: Split pstore fragile flags
This patch adds new PSTORE_FLAGS for each pstore type so that they can
be enabled separately. This is a preparation for ongoing virtio-pstore
work to support those types flexibly.
The PSTORE_FLAGS_FRAGILE is changed to PSTORE_FLAGS_DMESG to preserve the
original behavior.
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Matt Fleming
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Namhyung Kim
---
drivers/acpi/apei/erst.c | 2 +-
drivers/firmware/efi/efi-pstore.c | 2 +-
fs/pstore/platform.c | 21 +
fs/pstore/ram.c | 2 ++
include/linux/pstore.h| 7 ++-
5 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
index 006c3894c6ea..f0cb7b0fbac8 100644
--- a/drivers/acpi/apei/erst.c
+++ b/drivers/acpi/apei/erst.c
@@ -937,7 +937,7 @@ static int erst_clearer(enum pstore_type_id type, u64 id,
int count,
static struct pstore_info erst_info = {
.owner = THIS_MODULE,
.name = "erst",
- .flags = PSTORE_FLAGS_FRAGILE,
+ .flags = PSTORE_FLAGS_DMESG,
.open = erst_open_pstore,
.close = erst_close_pstore,
.read = erst_reader,
diff --git a/drivers/firmware/efi/efi-pstore.c
b/drivers/firmware/efi/efi-pstore.c
index eac76a79a880..dcb61a6f7ea7 100644
--- a/drivers/firmware/efi/efi-pstore.c
+++ b/drivers/firmware/efi/efi-pstore.c
@@ -356,7 +356,7 @@ static int efi_pstore_erase(enum pstore_type_id type, u64
id, int count,
static struct pstore_info efi_pstore_info = {
.owner = THIS_MODULE,
.name = "efi",
- .flags = PSTORE_FLAGS_FRAGILE,
+ .flags = PSTORE_FLAGS_DMESG,
.open = efi_pstore_open,
.close = efi_pstore_close,
.read = efi_pstore_read,
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 588461bb2dd4..6e86b7ea095d 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -467,13 +467,14 @@ int pstore_register(struct pstore_info *psi)
if (pstore_is_mounted())
pstore_get_records(0);
- pstore_register_kmsg();
-
- if ((psi->flags & PSTORE_FLAGS_FRAGILE) == 0) {
+ if (psi->flags & PSTORE_FLAGS_DMESG)
+ pstore_register_kmsg();
+ if (psi->flags & PSTORE_FLAGS_CONSOLE)
pstore_register_console();
+ if (psi->flags & PSTORE_FLAGS_FTRACE)
pstore_register_ftrace();
+ if (psi->flags & PSTORE_FLAGS_PMSG)
pstore_register_pmsg();
- }
if (pstore_update_ms >= 0) {
pstore_timer.expires = jiffies +
@@ -497,10 +498,14 @@ EXPORT_SYMBOL_GPL(pstore_register);
void pstore_unregister(struct pstore_info *psi)
{
- pstore_unregister_pmsg();
- pstore_unregister_ftrace();
- pstore_unregister_console();
- pstore_unregister_kmsg();
+ if (psi->flags & PSTORE_FLAGS_PMSG)
+ pstore_unregister_pmsg();
+ if (psi->flags & PSTORE_FLAGS_FTRACE)
+ pstore_unregister_ftrace();
+ if (psi->flags & PSTORE_FLAGS_CONSOLE)
+ pstore_unregister_console();
+ if (psi->flags & PSTORE_FLAGS_DMESG)
+ pstore_unregister_kmsg();
free_buf_for_compression();
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index bd9812e83461..d08bfd611b11 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -539,6 +539,8 @@ static int ramoops_probe(struct platform_device *pdev)
goto fail_clear;
}
+ cxt->pstore.flags = PSTORE_FLAGS_ALL;
+
err = pstore_register(&cxt->pstore);
if (err) {
pr_err("registering with pstore failed\n");
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 831479f8df8f..3ba0c1af40e5 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -73,7 +73,12 @@ struct pstore_info {
void*data;
};
-#definePSTORE_FLAGS_FRAGILE1
+#define PSTORE_FLAGS_DMESG (1 << 0)
+#define PSTORE_FLAGS_CONSOLE (1 << 1)
+#define PSTORE_FLAGS_FTRACE(1 << 2)
+#define PSTORE_FLAGS_PMSG (1 << 3)
+
+#define PSTORE_FLAGS_ALL ((1 << 4) - 1)
extern int pstore_register(struct pstore_info *);
extern void pstore_unregister(struct pstore_info *);
--
2.8.0
Re: [PATCH] clk: probe common clock drivers earlier
2016-07-20 19:58 GMT+09:00 Geert Uytterhoeven : > On Sat, Jul 16, 2016 at 6:57 AM, Masahiro Yamada > wrote: >> 2016-07-16 11:11 GMT+09:00 Michael Turquette : >>> Quoting Masahiro Yamada (2016-05-05 00:57:17) Several SoCs implement platform drivers for clocks rather than CLK_OF_DECLARE(). Clocks should come earlier because they are prerequisites for many of other drivers. It will help to mitigate > > As are regulators, DMA engines, power domains, ..., but the actual ordering > needed depends on the SoC. Right. The *mitigate* is a keyword in my git-log. I am not saying this commit can completely suppress EPROBE_DEFER, but moving "obj-y += clk/" up is a right thing for *most* of SoCs. -- Best Regards Masahiro Yamada
Re: [PATCH] tty/vt/keyboard: use memdup_user().
On Fri, May 20, 2016 at 02:27:05PM +0200, Samuel Thibault wrote:
> Muhammad Falak R Wani, on Fri 20 May 2016 17:53:28 +0530, wrote:
> > Use memdup_user to duplicate a memory region from user-space to
> > kernel-space, instead of open coding using kmalloc & copy_from_user.
> >
> > Signed-off-by: Muhammad Falak R Wani
>
> Reviewed-by: Samuel Thibault
Applied, thank you.
>
> > ---
> > drivers/tty/vt/keyboard.c | 14 --
> > 1 file changed, 4 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> > index f973bfc..698ea43 100644
> > --- a/drivers/tty/vt/keyboard.c
> > +++ b/drivers/tty/vt/keyboard.c
> > @@ -1745,16 +1745,10 @@ int vt_do_diacrit(unsigned int cmd, void __user
> > *udp, int perm)
> > return -EINVAL;
> >
> > if (ct) {
> > - buf = kmalloc(ct * sizeof(struct kbdiacruc),
> > - GFP_KERNEL);
> > - if (buf == NULL)
> > - return -ENOMEM;
> > -
> > - if (copy_from_user(buf, a->kbdiacruc,
> > - ct * sizeof(struct kbdiacruc))) {
> > - kfree(buf);
> > - return -EFAULT;
> > - }
> > + buf = memdup_user(a->kbdiacruc,
> > + ct * sizeof(struct kbdiacruc));
> > + if (IS_ERR(buf))
> > + return PTR_ERR(buf);
> > }
> > spin_lock_irqsave(&kbd_event_lock, flags);
> > if (ct)
> > --
> > 1.9.1
> >
>
> --
> Samuel
> (03:13:14) bon
> (03:13:19) il est tard :p
> (03:13:25) c'est l'heure de manger
> (03:13:38) hm j'ai mangé à 1h moi, j'ai des horaires raisonnables
--
Dmitry
Re: [RFC 5/7] [media] ir-lirc-codec: do not handle any buffer for raw transmitters
Hi Sean, > > Raw transmitters receive the data which need to be sent to > > receivers from userspace as stream of bits, they don't require > > any handling from the lirc framework. > > No drivers of type RC_DRIVER_IR_RAW_TX should handle tx just like any > other device, so data should be provided as an array of u32 alternating > pulse-space. If your device does not handle input like that then convert > it into that format in the driver. Every other driver has to do some > sort of conversion of that kind. I don't see anything wrong here, that's how it works for example in Tizen or in Android for the boards I'm on: userspace sends a stream of bits that are then submitted to the IR as they are. If I change it to only pulse-space domain, then I wouldn't provide support for those platforms. Eventually I can add a new protocol. Andi
Re: [PATCH v3 1/4] lib/dlock-list: Distributed and lock-protected lists
On Wed, 20 Jul 2016, Waiman Long wrote: > Christoph, are you OK with Tejun's request to revert the name back to > percpu_list? Or do you still think the current name is better? The percpu structure contains a spinlock and may be remotely accessed? You are aware that other percpu variables that share the same cacheline will be negatively impacted by accesses from other processors? The role of percpu areas are to have memory areas where the code can expect that cachelines are exclusively there for that processor. How frequent are the remote accesses? If this is rare then ok.
Re: [PATCH net-next v2 3/3] net: dsa: mv88e6xxx: kill last locked reg_read
On Wed, Jul 20, 2016 at 06:18:36PM -0400, Vivien Didelot wrote: > Get rid of the last usage of the locked mv88e6xxx_reg_read function with > a new mv88e6xxx_port_read helper, useful later for chips with different > port registers base address. > > Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn Andrew
Re: [RFC 3/7] [media] rc-core: add support for IR raw transmitters
Hi Sean,
> > + if (dev->driver_type == RC_DRIVER_IR_RAW ||
> > + dev->driver_type == RC_DRIVER_IR_RAW_TX) {
>
> Here the if is wrong. It should be
> "if (dev->driver_type != RC_DRIVER_IR_RAW_TX)". Note that as result
> the decoder thread is not started, so patch 4 won't be needed either.
but I need the ir-lirc-codec as it handles the interface with
userspace and it calls the tx_ir and s_tx_carrier.
if I do "if (dev->driver_type != RC_DRIVER_IR_RAW_TX)" the
lirc-codec is not called and I would need to handle it on my
driver, but then we fall in the first version of the driver.
Thanks,
Andi
> > if (!raw_init) {
> > request_module_nowait("ir-lirc-codec");
> > raw_init = true;
Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: rework EEPROM access
On Wed, Jul 20, 2016 at 06:18:35PM -0400, Vivien Didelot wrote:
> The 6352 family of switches and compatibles provide a 8-bit address and
> 16-bit data access to an optional EEPROM.
>
> Newer chip such as the 6390 family slightly changed the access to 16-bit
> address and 8-bit data.
>
> This commit cleans up the EEPROM access code for 16-bit access and makes
> it easy to eventually introduce future support for 8-bit access.
>
> Here's a list of notable changes brought by this patch:
>
> - provide Global2 unlocked helpers for EEPROM commands
> - remove eeprom_mutex, only reg_lock is necessary for driver functions
> - eeprom_len is 0 for chip without EEPROM, so return it directly
> - the Running bit must be 0 before r/w, so wait for Busy *and* Running
> - remove now unused mv88e6xxx_wait and mv88e6xxx_reg_write
> - other than that, the logic (in _{get,set}_eeprom16) didn't change
>
> Chips with an 8-bit EEPROM access will require to implement the
> 8-suffixed variant of G2 helpers and the related flag:
>
> #define MV88E6XXX_FLAGS_EEPROM8 \
> (MV88E6XXX_FLAG_G2_EEPROM_CMD | \
>MV88E6XXX_FLAG_G2_EEPROM_ADDR)
>
> Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Andrew
