Re: [PATCH] mellanox: mlx5: Use logging functions to reduce text ~10k/5%
On Wed, Jun 22, 2016 at 11:23:59AM -0700, Joe Perches wrote: > The logging macros create a bit of duplicated code/text. > > Use specialized functions to reduce the duplication. > > (defconfig/x86-64) > $ size drivers/net/ethernet/mellanox/mlx5/core/built-in.o* > text data bss dec hex filename > 178634 2059 16 180709 2c1e5 > drivers/net/ethernet/mellanox/mlx5/core/built-in.o.new > 188679 2059 16 190754 2e922 > drivers/net/ethernet/mellanox/mlx5/core/built-in.o.old > > The output changes now do not include line #, > but do include the function offset. > > Signed-off-by: Joe Perches As far as I see all these functions are used in error paths, so no implication on performance is expected. And I'm fine with function offsets. Saeed, What do you think? Reviewed-by: Leon Romanovsky signature.asc Description: Digital signature
Real-time summit 2016 - Call for presentations
This is a call for presentations for the Real-Time Summit which will be held in Berlin, Germany, on October 11th, 2016, at the Maritim Hotel Berlin. This event is co-located with Embedded Linux Conference Europe 2016. The Real-Time Summit is organized by the Linux Foundation Real-Time Linux (RTL) collaborative project (http://www.linuxfoundation.org/collaborate/workgroups/real-time). The event is intended to gather developers and users of the PREEMPT_RT patch. The main intent is to provide room for discussion between developers, tooling experts and users. If you are interested to present, please submit a proposal to rt-...@linutronix.de before July 15th, 2016, at 23:59 EST. Please provide a title, abstract describing the proposed talk (900 characters maximum), short biography (900 characters maximum), and describe the targeted audience (900 characters maximum). Please indicate the slot length you are aiming for: The format is a single track with presentation slots of 30 or 45 minutes length. The maximum presentation time is 15 resp. 20 minutes and the remaining time is reserved for discussion. The focus of this event is discussion. We are welcoming presentations from both end users and developers, on topics covering, but not limited to: * Real-time Linux development * Real-time Linux evaluation * Real-time Linux use cases (Success and failures) * Real-time Linux tooling (tracing, configuration, ...) Those can cover recently available technologies, ongoing work and new ideas. Please understand that this is not a place for presenting sales and marketing pitches or to advertise technology which is not related or not usable in the context of real-time Linux technology. This year, attending the Real-Time Summit is free of charge, and attendees are not required to register to other events. If you intend to attend, we recommend you don't wait too much before registering, as we need to consider room size limits. Further information about the event will be available at https://wiki.linuxfoundation.org/realtime/rt-summit2016. The Real-Time Summit is currently sponsored by the RTL collaborative project. Please let us know if your company is interested in sponsoring this event. Thank you, On behalf of the RTL collaborative project Thomas Gleixner
[PATCH] platform:x86 Remove Monitor MWAIT feature dependency
From: "Yu, Ong Hock"
Telemetry capability does not depend on Monitor MWAIT feature.
Signed-off-by: Yu, Ong Hock
---
drivers/platform/x86/intel_telemetry_debugfs.c | 2 +-
drivers/platform/x86/intel_telemetry_pltdrv.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel_telemetry_debugfs.c
b/drivers/platform/x86/intel_telemetry_debugfs.c
index f5134ac..d76ee59 100644
--- a/drivers/platform/x86/intel_telemetry_debugfs.c
+++ b/drivers/platform/x86/intel_telemetry_debugfs.c
@@ -78,7 +78,7 @@
#define TELEM_EVT_LEN(x) (sizeof(x)/sizeof((x)[0]))
#define TELEM_DEBUGFS_CPU(model, data) \
- { X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (unsigned long)&data}
+ { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&data}
#define TELEM_CHECK_AND_PARSE_EVTS(EVTID, EVTNUM, BUF, EVTLOG, EVTDAT, MASK) {
\
if (evtlog[index].telem_evtid == (EVTID)) { \
diff --git a/drivers/platform/x86/intel_telemetry_pltdrv.c
b/drivers/platform/x86/intel_telemetry_pltdrv.c
index 09c84a2..e62cee9 100644
--- a/drivers/platform/x86/intel_telemetry_pltdrv.c
+++ b/drivers/platform/x86/intel_telemetry_pltdrv.c
@@ -82,7 +82,7 @@
#define TELEM_SET_VERBOSITY_BITS(x, y) ((x) |= ((y) << 27))
#define TELEM_CPU(model, data) \
- { X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (unsigned long)&data }
+ { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&data }
enum telemetry_action {
TELEM_UPDATE = 0,
--
1.9.1
[PATCH] platform:x86: Remove Monitor MWAIT feature dependency
From: "Yu, Ong Hock" This patch is to remove the MWAIT feature dependency from the driver. Telemetry capability does not depend on this feature. Please include me in the mailing list as I did not subscripe to open list. Yu, Ong Hock (1): platform:x86 Remove Monitor MWAIT feature dependency drivers/platform/x86/intel_telemetry_debugfs.c | 2 +- drivers/platform/x86/intel_telemetry_pltdrv.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.9.1
linux-next: Tree for Jun 23
Hi all, Changes since 20160622: The pci tree gained a conflict against Linus' tree. The sunxi tree gained a conflict against the drm-misc tree. The audit tree gained a conflict against the security tree. Non-merge commits (relative to Linus' tree): 5152 4945 files changed, 228135 insertions(+), 97006 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 234 trees (counting Linus' and 34 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 (f9020d17416a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace) Merging fixes/master (5edb56491d48 Linux 4.7-rc3) Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported variables) Merging arc-current/for-curr (5edb56491d48 Linux 4.7-rc3) Merging arm-current/fixes (56530f5d2ddc ARM: 8579/1: mm: Fix definition of pmd_mknotpresent) Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic ) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (8550e2fa34f0 powerpc/mm/hash: Use the correct PPP mask when updating HPTE) 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 (acd43fe85b2d Merge branch 'mlx4-fixes') Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.) Merging ipvs/master (50219538ffc0 vmxnet3: segCnt can be 1 for LRO packets) Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git) Merging mac80211/master (3d5fdff46c4b wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel) Merging sound-current/for-linus (c9058d43d994 ALSA: hda/tegra: iomem fixups for sparse warnings) Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC code) Merging driver-core.current/driver-core-linus (e80dac114c63 Merge tag 'usb-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging tty.current/tty-linus (33688abb2802 Linux 4.7-rc4) Merging usb.current/usb-linus (33688abb2802 Linux 4.7-rc4) Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command) Merging usb-serial-fixes/usb-linus (33688abb2802 Linux 4.7-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: otg-fsm: add license to usb-otg-fsm) Merging staging.current/staging-linus (df013212a1b6 Merge tag 'iio-fixes-for-4.7b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (e80dac114c63 Merge tag 'usb-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging input-current/for-linus (30172936eefb MAINTAINERS: add Pali Rohár as reviewer of ALPS PS/2 touchpad driver) Merging crypto-current/master (19ced623db2f crypto: ux500 - memmove the right size) Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms vs module insertion race.) Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read) Merging kselftest-fixes/fixes (f80eb4289491 selftests/exec: Makefile is a run-time dependency, add it to the install list) Merging backlight-fixes/for-backlight-fixe
Re: [PATCH V4 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga
Hi Arnd, On Tue, 2016-06-21 at 11:34 +0200, Arnd Bergmann wrote: > On Tuesday, June 21, 2016 1:46:11 AM CEST th...@altera.com wrote: > > diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt > > b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt > > index 72d82d6..dd10f2f 100644 > > --- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt > > +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt > > @@ -17,9 +17,26 @@ Required properties: > > Optional properties: > > altr,emac-splitter: Should be the phandle to the emac splitter soft IP > > node if > > DWMAC controller is connected emac splitter. > > +phy-mode: The phy mode the ethernet operates in > > +altr,sgmii_to_sgmii_converter: phandle to the TSE SGMII converter > > + > > Please use '-' instead of '_' in the property names. Overlooked this when I were fixing v4, I'll get this fixed. > > Can you explain in the patch description why you can't reference > the converter using the normal "phy-handle" property and implement > the converter as a phy driver? > The converter isn't a PHY, but an adapter that handles data stream, and the phandle is only used to reset the adapter in software's context, thus it doesn't seem to be correct to implement it as a phy driver. Does that answer your question? If so, do you think we need to document this in the patch description in this case? > Arnd > Thanks Tien Hock
Re: Documenting ptrace access mode checking
On 06/22/2016 11:11 PM, Kees Cook wrote:
On Wed, Jun 22, 2016 at 12:21 PM, Michael Kerrisk (man-pages)
wrote:
On 06/21/2016 10:55 PM, Jann Horn wrote:
On Tue, Jun 21, 2016 at 11:41:16AM +0200, Michael Kerrisk (man-pages)
wrote:
5. The kernel LSM security_ptrace_access_check() interface is
invoked to see if ptrace access is permitted. The results
depend on the LSM. The implementation of this interface in
the default LSM performs the following steps:
For people who are unaware of how the LSM API works, it might be good to
clarify that the commoncap LSM is *always* invoked; otherwise, it might
give the impression that using another LSM would replace it.
As we can see, I am one of those who are unaware of how the LSM API
works :-/.
(Also, are there other documents that refer to it as "default LSM"? I
think that that term is slightly confusing.)
No, that's a terminological confusion of my own making. Fixed now.
I changed this text to:
Various parts of the kernel-user-space API (not just ptrace(2)
operations), require so-called "ptrace access mode permissions"
which are gated by any enabled Linux Security Module (LSMs)—for
example, SELinux, Yama, or Smack—and by the the commoncap LSM
(which is always invoked). Prior to Linux 2.6.27, all such
checks were of a single type. Since Linux 2.6.27, two access
mode levels are distinguished:
BTW, can you point me at the piece(s) of kernel code that show that
"commoncap" is always invoked in addition to any other LSM that has
been installed?
It's not entirely obvious, but the bottom of security/commoncap.c shows:
Thanks Kees!
Cheers,
Michael
#ifdef CONFIG_SECURITY
struct security_hook_list capability_hooks[] = {
LSM_HOOK_INIT(capable, cap_capable),
...
};
void __init capability_add_hooks(void)
{
security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks));
}
#endif
And security/security.c shows the initialization order of the LSMs:
int __init security_init(void)
{
pr_info("Security Framework initialized\n");
/*
* Load minor LSMs, with the capability module always first.
*/
capability_add_hooks();
yama_add_hooks();
loadpin_add_hooks();
/*
* Load all the remaining security modules.
*/
do_security_initcalls();
return 0;
}
-Kees
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length
On Wed, 22 Jun 2016, Zhaoyang Huang wrote: > On 20 June 2016 at 09:14, Zhaoyang Huang wrote: > > On 17 June 2016 at 19:50, Thomas Gleixner wrote: > >> On Fri, 17 Jun 2016, Zhaoyang Huang wrote: > >>> On 17 June 2016 at 17:27, Thomas Gleixner wrote: > >>> > On Fri, 17 Jun 2016, Zhaoyang Huang wrote: > >>> >> There should be a gap between tick_nohz_idle_enter and > >>> >> tick_nohz_get_sleep_length when idle, which will cause the > >>> >> sleep_length is not very precised. Change it in this patch. > >>> > > >>> > What kind of imprecision are we talking about? Seconds, nanoseconds or > >>> > lightyears? > >>> > > >>> > Your changelog lacks any form of useful information. > >>> > > >>> sorry for the confusion. The imprecision can be caused by, for > >>> example, the callback function registered for CPU_PM_ENTER, which may > >>> consume a period of time within the 'idle' time. Besides, I also > >>> wonder why not calc the 'sleep_length' in the > >>> tick_nohz_get_sleep_length? This value is calculated at very > >>> beginning of the idle in current approach. > >> > >> You still are not explaining the amount of imprecision. What are you > >> talking > >> about and is it really relevant in any way or are you just trying to solve > >> an > >> acedemic issue? > >> > >> Thanks, > >> > >> tglx > >> > > Indeed, it is depends on how deep the idle state is. For example, the > > lightest level for my current platform is 1100us, which sums up the > > entry,exit and min time. However, there is a callback which do memory > > management(merge the same page) in CPU_PM_ENTER will consume at least > > 500us. In current approach, it cause 50% imprecision for this level of > > idle state. > Hi Thomas, > Any further comments on that? Yes. Why on earth do we have a 500us callback in the idle entry path? That's just insane and needs to be fixed. Thanks, tglx
Re: Documenting ptrace access mode checking
Hi Oleg, On 06/22/2016 11:51 PM, Oleg Nesterov wrote: On 06/21, Eric W. Biederman wrote: Adding Oleg just because he seems to do most of the ptrace related maintenance these days. so I have to admit that I never even tried to actually understand ptrace_may_access ;) We certainly need something that gives a high level view so people reading the man page can know what to expect. If you get down into the weeds we run the danger of people beginning to think they can depend upon bugs in the implementation. Personally I agree. I think "man ptrace" shouldn't not tell too much about kernel internals. See my other replies on this topic. Somehow, we need a way of describing the behavior that user-space sees. I think it's inevitable that that means talking about what;s going on "under the hood". Regarding Eric's point that "we run the danger of people beginning to think they can depend upon bugs in the implementation": when it comes to breaking the ABI, the presence or absence of documentation doesn't save us on that point (Linus has a few times made his position wrt to documentation clear). Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH] x86: fix rdmsr MSR_PLATFORM_INFO unsafe warning in kvm guest
On Wed, 22 Jun 2016, Wanpeng Li wrote: > After commit (fc141535ad8 : "x86 tsc_msr: Extend to include Intel Core Where did you find that commit? It's neither in Linus tree nor in tip. Thanks, tglx
Re: [PATCH] mellanox: mlx5: Use logging functions to reduce text ~10k/5%
On Thu, Jun 23, 2016 at 08:27:01AM +0300, Leon Romanovsky wrote: > On Wed, Jun 22, 2016 at 11:23:59AM -0700, Joe Perches wrote: > > The logging macros create a bit of duplicated code/text. > > > > Use specialized functions to reduce the duplication. > > > > (defconfig/x86-64) > > $ size drivers/net/ethernet/mellanox/mlx5/core/built-in.o* > > text data bss dec hex filename > > 178634 2059 16 180709 2c1e5 > > drivers/net/ethernet/mellanox/mlx5/core/built-in.o.new > > 188679 2059 16 190754 2e922 > > drivers/net/ethernet/mellanox/mlx5/core/built-in.o.old > > > > The output changes now do not include line #, > > but do include the function offset. > > > > Signed-off-by: Joe Perches > > As far as I see all these functions are used in error paths, so no > implication on performance is expected. > > And I'm fine with function offsets. > > Saeed, > What do you think? > > Reviewed-by: Leon Romanovsky I continued to play with this patch and it doesn't pass checkpatch. It looks like corrupted file. ➜ linux-rdma git:(master) ./scripts/checkpatch.pl ~/Downloads/mellanox-mlx5-Use-logging-functions-to-reduce-text-10k-5.patch WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) #21: 178634 2059 16 180709 2c1e5 drivers/net/ethernet/mellanox/mlx5/core/built-in.o.new ERROR: patch seems to be corrupt (line wrapped?) #46: FILE: drivers/net/ethernet/mellanox/mlx5/core/main.c:1556: CHECK: Alignment should match open parenthesis #78: FILE: drivers/net/ethernet/mellanox/mlx5/core/main.c:1586: + dev_warn(&dev->pdev->dev, "%s:%pS:(pid %d): %pV", + dev->priv.name, __builtin_return_address(0), current->pid, ERROR: space required before that '&' (ctx:VxV) #79: FILE: drivers/net/ethernet/mellanox/mlx5/core/main.c:1587: + &vaf); ^ total: 2 errors, 1 warnings, 1 checks, 58 lines checked signature.asc Description: Digital signature
Re: [RESEND PATCH v11] mtd: spi-nor: add hisilicon spi-nor flash controller driver
Hi Cyrille,
On 2016/6/22 20:37, Cyrille Pitchen wrote:
> Hi Jiancheng,
>
> maybe a "depends on HAS_DMA" in the Kconfig may fix the kbuild test robot
> error.
> Otherwise your driver looks good now :)
>
Thank you very much for all comments. I'll fix this issue in the new version.
If there are no any other comments from others. I'll send the new version patch
out later.
Thanks,
Jiancheng
> Reviewed-by: Cyrille Pitchen
>
> Best regards,
>
> Cyrille
>
> Le 13/06/2016 10:21, Jiancheng Xue a écrit :
>> Add hisilicon spi-nor flash controller driver
>>
>> Signed-off-by: Binquan Peng
>> Signed-off-by: Jiancheng Xue
>> Acked-by: Rob Herring
>> Reviewed-by: Ezequiel Garcia
>> ---
>> change log
>> v11:
>> Fixed issues pointed by Brian Norris and Cyrille Pitchen.
>> 1)Changed hisi_spi_nor_read_reg()/write_reg() to configure registers
>> without sniffing the opcodes.
>> 2)Deleted hisi_spi_nor_erase() and used default implementation instead.
>> 3)Changed hisi_spi_nor_dma_transfer() to return a integer type value
>> instead of nothing.
>> 4)Simplified hisi_spi_nor_read()/write() as Brian suggested.
>>
>> v10:
>> Fixed issues pointed by Marek Vasut.
>> 1)Droped the underscores in the argument names of some macros' definition.
>> 2)Changed some varibles to correct type.
>> 3)Rewrote hisi_spi_nor_read/write for readability.
>> 4)Added new functions hisi_spi_nor_register/unregister_all
>> 5)Changed to dynamically allocation for spi_nor embeded in hifmc_host.
>> Fixed issues pointed by Brian Norris.
>> 1)Replaced some headers with more accurate ones.
>> v9:
>> Fixed issues pointed by Jagan Teki.
>> v8:
>> Fixed issues pointed by Ezequiel Garcia and Brian Norris.
>> Moved dts binding file to mtd directory.
>> Changed the compatible string more specific.
>> v7:
>> Rebased to v4.5-rc3.
>> Fixed issues pointed by Ezequiel Garcia.
>> v6:
>> Based on v4.5-rc2
>> Fixed issues pointed by Ezequiel Garcia.
>> v5:
>> Fixed a compile error.
>> v4:
>> Rebased to v4.5-rc1
>> v3:
>> Added a compatible string "hisilicon,hi3519-sfc".
>> v2:
>> Fixed some compiling warings.
>>
>> .../bindings/mtd/hisilicon,fmc-spi-nor.txt | 24 +
>> drivers/mtd/spi-nor/Kconfig| 7 +
>> drivers/mtd/spi-nor/Makefile | 1 +
>> drivers/mtd/spi-nor/hisi-sfc.c | 489
>> +
>> 4 files changed, 521 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
>> create mode 100644 drivers/mtd/spi-nor/hisi-sfc.c
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
>> b/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
>> new file mode 100644
>> index 000..7498152
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/hisilicon,fmc-spi-nor.txt
>> @@ -0,0 +1,24 @@
>> +HiSilicon SPI-NOR Flash Controller
>> +
>> +Required properties:
>> +- compatible : Should be "hisilicon,fmc-spi-nor" and one of the following
>> strings:
>> +"hisilicon,hi3519-spi-nor"
>> +- address-cells : Should be 1.
>> +- size-cells : Should be 0.
>> +- reg : Offset and length of the register set for the controller device.
>> +- reg-names : Must include the following two entries: "control", "memory".
>> +- clocks : handle to spi-nor flash controller clock.
>> +
>> +Example:
>> +spi-nor-controller@1000 {
>> +compatible = "hisilicon,hi3519-spi-nor", "hisilicon,fmc-spi-nor";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +reg = <0x1000 0x1000>, <0x1400 0x100>;
>> +reg-names = "control", "memory";
>> +clocks = <&clock HI3519_FMC_CLK>;
>> +spi-nor@0 {
>> +compatible = "jedec,spi-nor";
>> +reg = <0>;
>> +};
>> +};
>> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
>> index d42c98e..b9ff675 100644
>> --- a/drivers/mtd/spi-nor/Kconfig
>> +++ b/drivers/mtd/spi-nor/Kconfig
>> @@ -38,6 +38,13 @@ config SPI_FSL_QUADSPI
>>This controller does not support generic SPI. It only supports
>>SPI NOR.
>>
>> +config SPI_HISI_SFC
>> +tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
>> +depends on ARCH_HISI || COMPILE_TEST
>> +depends on HAS_IOMEM
>> +help
>> + This enables support for hisilicon SPI-NOR flash controller.
>> +
>> config SPI_NXP_SPIFI
>> tristate "NXP SPI Flash Interface (SPIFI)"
>> depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
>> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
>> index 0bf3a7f8..8a6fa69 100644
>> --- a/drivers/mtd/spi-nor/Makefile
>> +++ b/drivers/mtd/spi-nor/Makefile
>> @@ -1,4 +1,5 @@
>> obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o
>> obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o
>> +obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
>> obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o
>> obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o
>> diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/s
Re: [PATCH 4.6 38/81] gpio: bail out silently on NULL descriptors
On Thu, Jun 23, 2016 at 12:46 AM, Greg Kroah-Hartman wrote: > 4.6-stable review patch. If anyone has any objections, please let me know. This should ideally be paired with commit 79bb71bd1d93197ce227fa167b450b633f30a52b "gpio: make sure gpiod_to_irq() returns negative on NULL desc" which went upstream yesterday. Lest Hans de Goede will be unhappy. Yours, Linus Walleij
Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op
On Wed, 22 Jun 2016, Darren Hart wrote: > However, I don't think the patch below is correct. The existing logic > determines the type of timeout based on the futex_op when it should instead > determine the type of timeout based on the FUTEX_CLOCK_REALTIME flag. No. > My reading of the man page is that FUTEX_WAIT_BITSET abides by the timeout > interpretation defined by the FUTEX_CLOCK_REALTIME attribute, so > SYSCALL_DEFINE6 was misbehaving for FUTEX_WAIT|FUTEX_CLOCK_REALTIME (where the > timeout should have been treated as absolute) as well as for > FUTEX_WAIT_BITSET|FUTEX_CLOCK_MONOTONIC (where the timeout should have been > treated as relative). > > Consider the following: > > diff --git a/kernel/futex.c b/kernel/futex.c > index 33664f7..fa2af29 100644 > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -3230,7 +3230,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, > u32, val, > return -EINVAL; > > t = timespec_to_ktime(ts); > - if (cmd == FUTEX_WAIT) > + if (!(cmd & FUTEX_CLOCK_REALTIME)) > t = ktime_add_safe(ktime_get(), t); That breaks LOCK_PI, REQUEUE_PI and FUTEX_WAIT_BITSET > The concern for me is whether the code is incorrect, or if the man page is > incorrect. Does existing userspace code expect the FUTEX_WAIT_BITSET op to > always use an absolute timeout, regardless of the CLOCK used? FUTEX_WAIT_BITSET, LOCK_PI and REQUEUE_PI always expect absolute time in CLOCK_REALTIME independent of the CLOCK_REALTIME flag. The flag was explicitely added to allow FUTEX_WAIT to hand in absolute time. > > diff --git a/kernel/futex.c b/kernel/futex.c > > index 33664f7..4bee915 100644 > > --- a/kernel/futex.c > > +++ b/kernel/futex.c > > @@ -3230,7 +3230,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, > > u32, val, > > return -EINVAL; > > > > t = timespec_to_ktime(ts); > > - if (cmd == FUTEX_WAIT) > > + if (cmd == FUTEX_WAIT && !(op & FUTEX_CLOCK_REALTIME)) > > t = ktime_add_safe(ktime_get(), t); > > tp = &t; > > } So this patch is correct and if the man page is unclear about it then we need to fix that. Thanks, tglx
Re: Reported regressions for 4.7 as of Sunday, 2016-06-19
[+ Cc linux-s...@vger.kernel.org ]
On Wed, Jun 22, 2016 at 03:57:35PM +, Quinn Tran wrote:
> Johannes, Martin,
>
> Based on the screen shot/call trace, it looks like this adapter is not using
> MSIX. It defaulted back to MSI or INTx interrupt. The code made an
> assumption of MSIX is available. There is no point in go through that code
> segment.
>
> Can you try this work around? It’s untested. Thanks.
>
>
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index 5649c20..e033ecb 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -2548,7 +2548,7 @@ void qla24xx_process_response_queue(struct
> scsi_qla_host *vha,
> if (!vha->flags.online)
> return;
>
> - if (rsp->msix->cpuid != smp_processor_id()) {
> + if (rsp->msix && (rsp->msix->cpuid != smp_processor_id())) {
> /* if kernel does not notify qla of IRQ's CPU change,
> * then set it here.
> */
>
But this still does not fix the race which would be possible if the HBA is
using MSI-X but triggering IRQs early enough.
Have a look at this (I admit theoretical) path:
qla24xx_enable_msix(struct qla_hw_data *ha, struct rsp_que *rsp)
{
[...]
/* Enable MSI-X vectors for the base queue */
for (i = 0; i < 2; i++) {
qentry = &ha->msix_entries[i];
if (IS_P3P_TYPE(ha))
ret = request_irq(qentry->vector,
qla82xx_msix_entries[i].handler,
0, qla82xx_msix_entries[i].name, rsp);
else
ret = request_irq(qentry->vector,
msix_entries[i].handler,
0, msix_entries[i].name, rsp);
if (ret)
goto msix_register_fail;
<--- IRQ arrives here
qentry->have_irq = 1;
qentry->rsp = rsp;
rsp->msix = qentry;
[...]
void qla24xx_process_response_queue(struct scsi_qla_host *vha,
struct rsp_que *rsp)
{
[...]
if (rsp->msix->cpuid != smp_processor_id()) {
^
\--- rsp->msix == NULL
/* if kernel does not notify qla of IRQ's CPU change,
* then set it here.
*/
rsp->msix->cpuid = smp_processor_id();
ha->tgt.rspq_vector_cpuid = rsp->msix->cpuid;
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 1/5] gpio: of: optimize "gpios" property parsing of of_parse_own_gpio()
On Tue, Jun 14, 2016 at 12:07 PM, Masahiro Yamada wrote: > Call of_property_read_u32_array() only once rather than iterating > of_property_read_u32_index(). > > Signed-off-by: Masahiro Yamada Thanks patch applied! In this case I think the code is so old that the read_u32_array() function didn't exist when it was written. Yours, Linus Walleij
Re: [PATCH 1/2] leds: ncp5623: Add device tree binding documentation
On 06/22/2016 04:25 PM, Florian Vaussard wrote:
Hi Jacek,
Le 22. 06. 16 à 10:51, Jacek Anaszewski a écrit :
Hi Florian,
On 06/22/2016 08:08 AM, Florian Vaussard wrote:
Hi Jacek,
Le 21. 06. 16 à 17:28, Jacek Anaszewski a écrit :
Hi Florian,
Thanks for the patch. I have two remarks below.
On 06/21/2016 09:29 AM, Florian Vaussard wrote:
Add device tree binding documentation for On Semiconductor NCP5623 I2C
LED driver. The driver can independently control the PWM of the 3
channels with 32 levels of intensity.
The current delivered by the current source can be controlled using the
led-max-microamp property. In order to control this value, it is also
necessary to know the current on the Iref pin, hence the
onnn,led-iref-microamp property. It is usually set using an external
bias resistor, following Iref = Vref/Rbias with Vref=0.6V.
Signed-off-by: Florian Vaussard
---
.../devicetree/bindings/leds/leds-ncp5623.txt | 44
++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-ncp5623.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
b/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
new file mode 100644
index 000..0dc8345
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
@@ -0,0 +1,44 @@
+* ON Semiconductor - NCP5623 3-Channel LED Driver
+
+The NCP5623 is a 3-channel I2C LED driver. The brightness of each
+channel can be independently set using 32 levels. Each LED is represented
+as a sub-node of the device.
+
+Required properties:
+ - compatible: Should be "onnn,ncp5623"
+ - reg: I2C slave address (fixed to 0x38)
+ - #address-cells: must be 1
+ - #size-cells: must be 0
+ - onnn,led-iref-microamp: Current on the Iref pin in microampere
I think that you don't need this property. Just provide the formula for
calculating led-max-microamp value, similarly as you're doing that in
the commit message.
I am not completely sure to understand your suggestion. So at the end, I have to
compute the value of the register (let call it 'ILED') that I need to send to
chip to configure the current source. The formula is:
ILED = 31 - 2400*Iref/led-max-microamp
led-max-microamp is the maximum current value for given LED.
According to the documentation it can be calculated as follows:
ILEDmax = Iref * 2400 / (31 - n)
Since this is global setting for all LEDs, then I'd always set n to 30,
and calculate max_brightness value for each LED separately, basing on
led-max-microamp property value. Effectively, I'm revoking my previous
statement about setting max_brightness to fixed level.
Ok your proposal simplifies a bit the handling. Thus ILEDmax of the current
source would be always equal to Iref * 2400 and we use the PWM to limit the
current inside the LED. The only downside of this approach is a reduced number
of possible PWM steps, thus a limited number of RGB colors.
Yes, but by max_brightness being always 31, lowering led-max-microamp
results in decreasing the amount of current per brightness level.
Effectively, a human ability to notice perceived brightness level
change also decreases then.
In the approach I proposed this limitation is reflected in reduced
amount of available brightness levels.
Regarding the DT binding, this would mean something like this:
ncp5623@38 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "onnn,ncp5623";
reg = <0x38>;
led-max-microamp = <3>;
Please drop it from here. It doesn't need to be configurable.
You can hard code this in the driver.
ledr@0 {
label = "ncp:power:red";
reg = <0>;
linux,default-trigger = "default-on";
led-max-microamp = <5000>;
Is 5mA the maximum allowed current value for the LEDs on the board
you're using? Is brightness level change easily noticeable by max
current set to 5mA and max_brightness set to 31? It would be good
to empirically check this configuration.
};
ledb@1 {
label = "ncp:power:blue";
reg = <1>;
led-max-microamp = <5000>;
};
ledg@2 {
label = "ncp:power:green";
reg = <2>;
led-max-microamp = <5000>;
};
};
The led-max-microamp property of the root node is used to infer Iref, and the
led-max-microamp property inside each LED node is used to compute the maximum
allowed PWM ratio (thus max_brightness).
Would it be fine like this?
You can compare drivers/leds/leds-aat1290.c and its bindings, as it
uses similar approach.
Thanks for the pointer, interesting reading. In this case the flash-max-microamp
property is implicitly used to get the value of Rset, and led-max-microamp is
used to compute the flash/movie-mode ratio. Indeed similar but not exactly the
same, as the NCP5623 allows a finer control on the current using one register to
c
Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data
On Wed, 2016-06-15 at 16:28 +0200, Benjamin Tissoires wrote: > On Jun 13 2016 or thereabouts, Andy Shevchenko wrote: > > On Fri, 2016-06-03 at 15:32 +0200, Benjamin Tissoires wrote: > > > On Jun 03 2016 or thereabouts, Andy Shevchenko wrote: > > > > On Fri, 2016-06-03 at 14:23 +0200, Benjamin Tissoires wrote: > > > > > > > > > On Jun 03 2016 or thereabouts, Andy Shevchenko wrote: > > > > > > On Fri, 2016-06-03 at 11:38 +0200, Benjamin Tissoires wrote: > > > > > > > On Jun 02 2016 or thereabouts, Andy Shevchenko wrote: > > > > > > > > On Thu, 2016-06-02 at 16:11 +0200, Benjamin Tissoires > > > > > > > > wrote: > > > > > > > > > > > > > > > > I take linux-next + your two patches from this thread (+ > > > > > > > > some > > > > > > > > unrelated > > > > > > > > to HID patches). > > > > > > > > > > > > > > OK. I think I know what happened: > > > > > > > - Microsoft forgot to put the Win 8 certification blob in > > > > > > > this > > > > > > > particular device (of course, because Microsoft) > > > > > > > - we do not detect it as a Win 8 certified and do not set > > > > > > > the > > > > > > > HID_QUIRK_NO_INIT_REPORTS flag > > > > > > > - your dmesg should show some error on plug, and then hid > > > > > > > can't > > > > > > > set > > > > > > > the > > > > > > > input mode > > > > > > > - I can't add a "if win 8 then show the mouse collection" > > > > > > > because > > > > > > > your > > > > > > > device doesn't report itself as win 8 :) > > > > > > > > > > > > > > Anyway, could you try applying this small diff after my 2 > > > > > > > patches > > > > > > > and > > > > > > > report if you now have a working touchpad?: > > > > > > > > > > > > Nope. There is still no /dev/input/eventX associated with > > > > > > touchpad. > > > > > > > > > > Weird. On my system, if I replay your logs, I see 4 new nodes: > > > > > /dev/input/event21: Microsoft Surface Keyboard Keyboard > > > > > /dev/input/event22: Microsoft Surface Keyboard Consumer > > > > > Control > > > > > /dev/input/event23: Microsoft Surface Keyboard Touchpad > > > > > /dev/input/event24: Microsoft Surface Keyboard Keyboard > > > > > > > > I had a line in dmesg that input8 is allocated to Touchpad, but > > > > no > > > > eventX (0..6 IIRC) from /dev/input reflects Touchpad events. I > > > > can > > > > get > > > > them only via /dev/usb/hiddev0. > > > > > > > > > > > > > > Can you attach the dmesg when plugging in the type cover? > > > > > > > > > > > > > I will do later, but there is no such thing 'plugging in'. It's > > > > a > > > > part > > > > of the notebook, so, I can do detach-attach cycle, though it > > > > shouldn't > > > > matter, it should work immediately after boot I suppose. > > > > > > > > > > Actually, if the touchpad doesn't want to be set to the multitouch > > > mode, > > > we might as well take your v2 of your patch in addition to this > > > series. > > > This should hopefully make the caps lock LED happy and at least > > > enable > > > the mouse collection. If someone wants to debug why the device > > > doesn't > > > want to switch to mt, I'd be happy to help/review patches, but I > > > think > > > we might as well take the easiest path :) > > > > > > So Andy, if you still have the energy for this: > > > please apply this series and yours > > > (https://patchwork.kernel.org/patch/9069371/) > > > > > > And report if this is sufficient enough. > > > > Attached dmesg and hid-recorder files. Doesn't work. In dmesg it > > complained on USB transfer at some point during boot. > > > > Could you please double check your tree? The error in the dmesg can't > happen if you applied https://patchwork.kernel.org/patch/9069371/ > which > sets the quirk HID_QUIRK_NO_INIT_REPORTS. > > In usbhid_start(), we check for this quirk before entering the only > function that contains the error "timeout initializing reports\n". > (hiddev has an ioctl that can call it, but I assume you don't have any > userspace tool calling it, that would be insane). > > So, your tree should have: > - latest Jiri's for-next branch (I usually merge it with the latest > official rc) > - https://patchwork.kernel.org/patch/9081731/ > - https://patchwork.kernel.org/patch/9081761/ > - https://patchwork.kernel.org/patch/9069371/ Yes, that's how it looks like. Actually the branch I'm using is public https://bitbucket.org/andy-shev/ linux/branch/topic%2Fdw%2Fqrk P.S. Let me couple of days I will test once more to be sure. -- Andy Shevchenko Intel Finland Oy
Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length
On 23 June 2016 at 15:01, Thomas Gleixner wrote: > On Wed, 22 Jun 2016, Zhaoyang Huang wrote: >> On 20 June 2016 at 09:14, Zhaoyang Huang wrote: >> > On 17 June 2016 at 19:50, Thomas Gleixner wrote: >> >> On Fri, 17 Jun 2016, Zhaoyang Huang wrote: >> >>> On 17 June 2016 at 17:27, Thomas Gleixner wrote: >> >>> > On Fri, 17 Jun 2016, Zhaoyang Huang wrote: >> >>> >> There should be a gap between tick_nohz_idle_enter and >> >>> >> tick_nohz_get_sleep_length when idle, which will cause the >> >>> >> sleep_length is not very precised. Change it in this patch. >> >>> > >> >>> > What kind of imprecision are we talking about? Seconds, nanoseconds or >> >>> > lightyears? >> >>> > >> >>> > Your changelog lacks any form of useful information. >> >>> > >> >>> sorry for the confusion. The imprecision can be caused by, for >> >>> example, the callback function registered for CPU_PM_ENTER, which may >> >>> consume a period of time within the 'idle' time. Besides, I also >> >>> wonder why not calc the 'sleep_length' in the >> >>> tick_nohz_get_sleep_length? This value is calculated at very >> >>> beginning of the idle in current approach. >> >> >> >> You still are not explaining the amount of imprecision. What are you >> >> talking >> >> about and is it really relevant in any way or are you just trying to >> >> solve an >> >> acedemic issue? >> >> >> >> Thanks, >> >> >> >> tglx >> >> >> > Indeed, it is depends on how deep the idle state is. For example, the >> > lightest level for my current platform is 1100us, which sums up the >> > entry,exit and min time. However, there is a callback which do memory >> > management(merge the same page) in CPU_PM_ENTER will consume at least >> > 500us. In current approach, it cause 50% imprecision for this level of >> > idle state. >> Hi Thomas, >> Any further comments on that? > > Yes. Why on earth do we have a 500us callback in the idle entry path? That's > just insane and needs to be fixed. > > Thanks, > > tglx Thomas, I agree with you, I have discussed the modification with the call back owner. However, I wonder if we can make the idle's framework to be more precised without the assumption of short CPU_PM_ENTER callbacks. Thank you!
Re: [PATCH] x86: fix rdmsr MSR_PLATFORM_INFO unsafe warning in kvm guest
2016-06-23 15:09 GMT+08:00 Thomas Gleixner : > On Wed, 22 Jun 2016, Wanpeng Li wrote: >> After commit (fc141535ad8 : "x86 tsc_msr: Extend to include Intel Core > > Where did you find that commit? It's neither in Linus tree nor in tip. It is reported by lkp. https://lkml.org/lkml/2016/6/20/110 The patch is against x86 branch on Len Brown's tree. And try to fix this commit: https://git.kernel.org/cgit/linux/kernel/git/lenb/linux.git/commit/?h=x86&id=fc141535ad8a67fd58623289c04e35465e2a07f2
Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.
Andrew Pinski writes: > So if you want aarch64 to be compatible with aarch32, you need to > define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and > aarch32 to be compatible at all, then we can drop this patch or if you > don't want LP64 and ILP32 to be compatible either. Or go the other way like s390 and use the LP64 layout for ILP32. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH 2/5] gpio: of: drop needless gpio_chip look-up in of_parse_own_gpio()
On Tue, Jun 14, 2016 at 12:07 PM, Masahiro Yamada wrote: > This function is doing more complicated than needed. The caller of > this function, of_gpiochip_scan_gpios() already knows the pointer to > the gpio_chip. It can pass it to of_parse_own_gpio() instead of > looking up the gpio_chip by gpiochip_find(). > > Signed-off-by: Masahiro Yamada Patch applied! First I was worried about this semantic change: > - chip_np = np->parent; > + chip_np = chip->of_node; But then I read up on the code and saw that of_gpiochip_add() sets it to the parent if not set before. Yours, Linus Walleij
Re: [PATCH] x86: fix rdmsr MSR_PLATFORM_INFO unsafe warning in kvm guest
Hi Jacob, 2016-06-23 15:28 GMT+08:00 Wanpeng Li : > 2016-06-23 15:09 GMT+08:00 Thomas Gleixner : >> On Wed, 22 Jun 2016, Wanpeng Li wrote: >>> After commit (fc141535ad8 : "x86 tsc_msr: Extend to include Intel Core >> >> Where did you find that commit? It's neither in Linus tree nor in tip. > > It is reported by lkp. https://lkml.org/lkml/2016/6/20/110 The patch > is against x86 branch on Len Brown's tree. And try to fix this commit: > https://git.kernel.org/cgit/linux/kernel/git/lenb/linux.git/commit/?h=x86&id=fc141535ad8a67fd58623289c04e35465e2a07f2 I prefer this patch can be applied separately instead of fold into the bad commit since it shows the issue when access MSR_PLATFORM_INFO in kvm guest and other guys who want to access MSR_PLATFORM_INFO later can find the changelog and make better decisions. Regards, Wanpeng Li
Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.
On Thu, Jun 23, 2016 at 09:32:46AM +0200, Andreas Schwab wrote: > Andrew Pinski writes: > > > So if you want aarch64 to be compatible with aarch32, you need to > > define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and > > aarch32 to be compatible at all, then we can drop this patch or if you > > don't want LP64 and ILP32 to be compatible either. > > Or go the other way like s390 and use the LP64 layout for ILP32. > > Andreas. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different." It was an agreement that we don't fix Y2038 issues specifically, as there will be general fix.
Re: [PATCH 3/5] gpio: of: move chip->of_gpio_n_cells checking to of_gpiochip_add()
On Tue, Jun 14, 2016 at 12:07 PM, Masahiro Yamada wrote: > Do this sanity check only once when the gpio_chip is added > rather than every time gpio-hog is handled. > > Signed-off-by: Masahiro Yamada Patch applied. Yours, Linus Walleij
[PATCH v3] mfd: intel_soc_pmic_bxtwc: Add Intel BXT WhiskeyCove PMIC ADC thermal channel mapping and USB type-C resources
This patch adds the mapping of PMIC ADC channel to thermal zone and
USB type-C resources. This mapping is used in the pmic thermal driver
to notify the thermal zone with the pmic adc channel alert interrupts.
This patch also adds three new data structures to
include/linux/mfd/intel_soc_pmic.h: struct trip_config_map{},
struct thermal_irq_map {} and struct pmic_thermal_data {} which are
required by changes we did on intel_soc_pmic_bxtwc.c.
Signed-off-by: Yegnesh S Iyer
Signed-off-by: Rohit S Kenchanpura
Signed-off-by: Bin Gao
---
Changes in v3:
- Added USB type-C resources.
Changes in v2:
- Fixed subject line.
- Combined two patches into one.
drivers/mfd/intel_soc_pmic_bxtwc.c | 120 +
include/linux/mfd/intel_soc_pmic.h | 21 +++
2 files changed, 141 insertions(+)
diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index b942876..9eacaf2 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -58,6 +58,10 @@
#define BXTWC_MGPIO1IRQ0x4E1A
#define BXTWC_MCRITIRQ 0x4E1B
+#define BXTWC_STHRM0IRQ0x4F19
+#define BXTWC_STHRM1IRQ0x4F1A
+#define BXTWC_STHRM2IRQ0x4F1B
+
/* Whiskey Cove PMIC share same ACPI ID between different platforms */
#define BROXTON_PMIC_WC_HRV4
@@ -84,6 +88,7 @@ enum bxtwc_irqs_level2 {
BXTWC_THRM2_IRQ,
BXTWC_BCU_IRQ,
BXTWC_ADC_IRQ,
+ BXTWC_USBC_IRQ,
BXTWC_CHGR0_IRQ,
BXTWC_CHGR1_IRQ,
BXTWC_GPIO0_IRQ,
@@ -110,12 +115,116 @@ static const struct regmap_irq
bxtwc_regmap_irqs_level2[] = {
REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 3, 0x1f),
REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 4, 0xff),
REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 5, 0x1f),
+ REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 5, BIT(5)),
REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 6, 0x1f),
REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 7, 0xff),
REGMAP_IRQ_REG(BXTWC_GPIO1_IRQ, 8, 0x3f),
REGMAP_IRQ_REG(BXTWC_CRIT_IRQ, 9, 0x03),
};
+static struct trip_config_map str0_trip_config[] = {
+ {
+ .irq_reg = BXTWC_THRM0IRQ,
+ .irq_mask = 0x01,
+ .irq_en = BXTWC_MTHRM0IRQ,
+ .irq_en_mask = 0x01,
+ .evt_stat = BXTWC_STHRM0IRQ,
+ .evt_mask = 0x01,
+ .trip_num = 0
+ },
+ {
+ .irq_reg = BXTWC_THRM0IRQ,
+ .irq_mask = 0x10,
+ .irq_en = BXTWC_MTHRM0IRQ,
+ .irq_en_mask = 0x10,
+ .evt_stat = BXTWC_STHRM0IRQ,
+ .evt_mask = 0x10,
+ .trip_num = 1
+ }
+};
+
+static struct trip_config_map str1_trip_config[] = {
+ {
+ .irq_reg = BXTWC_THRM0IRQ,
+ .irq_mask = 0x02,
+ .irq_en = BXTWC_MTHRM0IRQ,
+ .irq_en_mask = 0x02,
+ .evt_stat = BXTWC_STHRM0IRQ,
+ .evt_mask = 0x02,
+ .trip_num = 0
+ },
+ {
+ .irq_reg = BXTWC_THRM0IRQ,
+ .irq_mask = 0x20,
+ .irq_en = BXTWC_MTHRM0IRQ,
+ .irq_en_mask = 0x20,
+ .evt_stat = BXTWC_STHRM0IRQ,
+ .evt_mask = 0x20,
+ .trip_num = 1
+ },
+};
+
+static struct trip_config_map str2_trip_config[] = {
+ {
+ .irq_reg = BXTWC_THRM0IRQ,
+ .irq_mask = 0x04,
+ .irq_en = BXTWC_MTHRM0IRQ,
+ .irq_en_mask = 0x04,
+ .evt_stat = BXTWC_STHRM0IRQ,
+ .evt_mask = 0x04,
+ .trip_num = 0
+ },
+ {
+ .irq_reg = BXTWC_THRM0IRQ,
+ .irq_mask = 0x40,
+ .irq_en = BXTWC_MTHRM0IRQ,
+ .irq_en_mask = 0x40,
+ .evt_stat = BXTWC_STHRM0IRQ,
+ .evt_mask = 0x40,
+ .trip_num = 1
+ },
+};
+
+static struct trip_config_map str3_trip_config[] = {
+ {
+ .irq_reg = BXTWC_THRM2IRQ,
+ .irq_mask = 0x10,
+ .irq_en = BXTWC_MTHRM2IRQ,
+ .irq_en_mask = 0x10,
+ .evt_stat = BXTWC_STHRM2IRQ,
+ .evt_mask = 0x10,
+ .trip_num = 0
+ },
+};
+
+static struct thermal_irq_map bxtwc_thermal_irq_map[] = {
+ {
+ .handle = "STR0",
+ .trip_config = str0_trip_config,
+ .num_trips = ARRAY_SIZE(str0_trip_config),
+ },
+ {
+ .handle = "STR1",
+ .trip_config = str1_trip_config,
+ .num_trips = ARRAY_SIZE(str1_trip_config),
+ },
+ {
+ .handle = "STR2",
+ .trip_config = str2_trip_config,
+ .num_trips = ARRAY_SIZE(str2_trip_config),
+ },
+ {
+ .handle = "STR3",
+ .trip_config = str3_trip_config,
+ .num_trips =
Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.
On Thu, Jun 23, 2016 at 12:32 AM, Andreas Schwab wrote: > Andrew Pinski writes: > >> So if you want aarch64 to be compatible with aarch32, you need to >> define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and >> aarch32 to be compatible at all, then we can drop this patch or if you >> don't want LP64 and ILP32 to be compatible either. > > Or go the other way like s390 and use the LP64 layout for ILP32. That will solve the ILP32 side of things and I am ok with doing that but not it does not solve that right now AARCH32 and AARCH64 are incompatible. You could say AARCH64 LP64 is currently broken because of this incompatible but nobody has complained until now. So the question becomes do we care enough about the incompatibles between AARCH32 and AARCH64 to fix this and go just worry about ILP32 and LP64? Thanks, Andrew > > Andreas. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."
Re: [LKP] [PATCH] x86: fix rdmsr MSR_PLATFORM_INFO unsafe warning in kvm guest
On Thu, Jun 23, 2016 at 3:09 PM, Thomas Gleixner wrote: > On Wed, 22 Jun 2016, Wanpeng Li wrote: >> After commit (fc141535ad8 : "x86 tsc_msr: Extend to include Intel Core > > Where did you find that commit? It's neither in Linus tree nor in tip. > It is in Len's tree, we are planing to resend the patchset with Wanpeng's fix merged with a credit to him in commit msg, thanks for Wanpeng's effort. thanks all.
Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.
On Thu, Jun 23, 2016 at 12:36 AM, Yury Norov wrote: > On Thu, Jun 23, 2016 at 09:32:46AM +0200, Andreas Schwab wrote: >> Andrew Pinski writes: >> >> > So if you want aarch64 to be compatible with aarch32, you need to >> > define __WORDSIZE_TIME64_COMPAT32. If we don't want aarch64 and >> > aarch32 to be compatible at all, then we can drop this patch or if you >> > don't want LP64 and ILP32 to be compatible either. >> >> Or go the other way like s390 and use the LP64 layout for ILP32. >> >> Andreas. >> >> -- >> Andreas Schwab, SUSE Labs, sch...@suse.de >> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 >> "And now for something completely different." > > It was an agreement that we don't fix Y2038 issues specifically, as > there will be general fix. Except that was the agreement for ILP32 what about AARCH32 and AARCH64 LP64 where is a known issue right now. ARM and AARCH64 maintainers please chime in about this issue. Thanks, Andrew
Re: [LKP] [PATCH] x86: fix rdmsr MSR_PLATFORM_INFO unsafe warning in kvm guest
Hi Yu， 2016-06-23 15:37 GMT+08:00 Yu Chen : > On Thu, Jun 23, 2016 at 3:09 PM, Thomas Gleixner wrote: >> On Wed, 22 Jun 2016, Wanpeng Li wrote: >>> After commit (fc141535ad8 : "x86 tsc_msr: Extend to include Intel Core >> >> Where did you find that commit? It's neither in Linus tree nor in tip. >> > It is in Len's tree, we are planing to resend the patchset with Wanpeng's fix > merged with a credit to him in commit msg, thanks for Wanpeng's effort. > thanks all. I prefer this patch can be applied separately instead of fold into the bad commit since it shows the issue when access MSR_PLATFORM_INFO in kvm guest and other guys who want to access MSR_PLATFORM_INFO later can find the changelog and make better decisions. Regards, Wanpeng Li
[PATCH v2 2/2] arm64: tegra: Add VDD_GPU regulator to Jetson TX1
Add the VDD_GPU regulator (a GPIO-enabled PWM regulator) to the Jetson
TX1 board. This addition allows the GPU to be used provided the
bootloader properly enabled the GPU node.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
- Include this patch into the series to make sure it is merged after 1/2,
otherwise Jetson TX1 will lock when trying to enable the regulator.
arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
b/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
index 983775e637a4..cc9fb5207f9d 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
@@ -25,6 +25,10 @@
};
};
+ gpu@5700 {
+ vdd-supply = <&vdd_gpu>;
+ };
+
i2c@7000c400 {
backlight: backlight@2c {
compatible = "ti,lp8557";
@@ -51,4 +55,18 @@
};
};
};
+
+ regulators {
+ vdd_gpu: regulator@100 {
+ compatible = "pwm-regulator";
+ reg = <100>;
+ pwms = <&pwm 1 4880>;
+ regulator-name = "VDD_GPU";
+ regulator-min-microvolt = <71>;
+ regulator-max-microvolt = <132>;
+ enable-gpios = <&pmic 6 GPIO_ACTIVE_HIGH>;
+ regulator-ramp-delay = <80>;
+ regulator-enable-ramp-delay = <1000>;
+ };
+ };
};
--
2.8.3
[PATCH v2 1/2] regulator: pwm: Support for enable GPIO
Add an optional enable GPIO to the pwm-regulator driver.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
- Do not try to be smart and use the core enable GPIO as this introduces an
incompatible behavior. Probe and manipulate the GPIO in pwm-regulator.
- Use standard enable-gpios name for GPIO property
.../bindings/regulator/pwm-regulator.txt | 7 +-
drivers/regulator/pwm-regulator.c | 26 ++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index ed936f0f34f2..dd6f59cf1455 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -38,13 +38,18 @@ NB: To be clear, if voltage-table is provided, then the
device will be used
in Voltage Table Mode. If no voltage-table is provided, then the device will
be used in Continuous Voltage Mode.
+Optional properties:
+
+- enable-gpios:GPIO to use to enable/disable the regulator
+
Any property defined as part of the core regulator binding can also be used.
(See: ../regulator/regulator.txt)
-Continuous Voltage Example:
+Continuous Voltage With Enable GPIO Example:
pwm_regulator {
compatible = "pwm-regulator;
pwms = <&pwm1 0 8448 0>;
+ enable-gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;
regulator-min-microvolt = <1016000>;
regulator-max-microvolt = <1114000>;
regulator-name = "vdd_logic";
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
index ab3cc0235843..90f8b7fd0437 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
struct pwm_regulator_data {
/* Shared */
@@ -38,6 +39,9 @@ struct pwm_regulator_data {
/* Continuous voltage */
int volt_uV;
+
+ /* Enable GPIO */
+ struct gpio_desc *enb_gpio;
};
struct pwm_voltages {
@@ -94,6 +98,9 @@ static int pwm_regulator_enable(struct regulator_dev *dev)
{
struct pwm_regulator_data *drvdata = rdev_get_drvdata(dev);
+ if (drvdata->enb_gpio)
+ gpiod_set_value_cansleep(drvdata->enb_gpio, 1);
+
return pwm_enable(drvdata->pwm);
}
@@ -103,6 +110,9 @@ static int pwm_regulator_disable(struct regulator_dev *dev)
pwm_disable(drvdata->pwm);
+ if (drvdata->enb_gpio)
+ gpiod_set_value_cansleep(drvdata->enb_gpio, 0);
+
return 0;
}
@@ -110,6 +120,9 @@ static int pwm_regulator_is_enabled(struct regulator_dev
*dev)
{
struct pwm_regulator_data *drvdata = rdev_get_drvdata(dev);
+ if (drvdata->enb_gpio && !gpiod_get_value_cansleep(drvdata->enb_gpio))
+ return false;
+
return pwm_is_enabled(drvdata->pwm);
}
@@ -248,6 +261,7 @@ static int pwm_regulator_probe(struct platform_device *pdev)
struct regulator_dev *regulator;
struct regulator_config config = { };
struct device_node *np = pdev->dev.of_node;
+ enum gpiod_flags gpio_flags;
int ret;
if (!np) {
@@ -285,6 +299,18 @@ static int pwm_regulator_probe(struct platform_device
*pdev)
return ret;
}
+ if (init_data->constraints.boot_on || init_data->constraints.always_on)
+ gpio_flags = GPIOD_OUT_HIGH;
+ else
+ gpio_flags = GPIOD_OUT_LOW;
+ drvdata->enb_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
+ gpio_flags);
+ if (IS_ERR(drvdata->enb_gpio)) {
+ ret = PTR_ERR(drvdata->enb_gpio);
+ dev_err(&pdev->dev, "Failed to get enable GPIO: %d\n", ret);
+ return ret;
+ }
+
/*
* FIXME: pwm_apply_args() should be removed when switching to the
* atomic PWM API.
--
2.8.3
RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core
Hi, > From: Peter Chen > Sent: Wednesday, June 22, 2016 12:34 PM > > On Tue, Jun 21, 2016 at 05:47:47PM +0300, Felipe Balbi wrote: > > > > Hi, > > > > Peter Chen writes: > > >> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used > > >> >> >> >> >>> with OTG core. > > >> >> >> >> >> > > >> >> >> >> >> do you really know of any platform which has a separate OTG > > >> >> >> >> >> controller? > > >> >> >> >> >> > > >> >> >> >> > > > >> >> >> >> > Andrew had pointed out in [1] that Tegra210 has separate > > >> >> >> >> > blocks for OTG, host > > >> >> >> >> > and gadget. > > >> >> >> >> > > > >> >> >> >> > [1] http://article.gmane.org/gmane.linux.ports.tegra/22969 > > >> >> >> >> > > >> >> >> >> that's not an OTG controller, it's just a mux. No different > > >> >> >> >> than Intel's > > >> >> >> >> mux for swapping between XHCI and peripheral-only DWC3. > > >> >> >> >> > > >> >> >> >> frankly, I would NEVER talk about OTG when type-C comes into > > >> >> >> >> play. They > > >> >> >> >> are two competing standards and, apparently, type-C is winning > > >> >> >> >> when it > > >> >> >> >> comes to role-swapping. > > >> >> >> >> > > >> >> >> > > > >> >> >> > In fact, OTG is mis-used by people. Currently, if the port is > > >> >> >> > dual-role, > > >> >> >> > It will be considered as an OTG port. > > >> >> >> > > >> >> >> That's because "dual-role" is a non-standard OTG. Seen as people > > >> >> >> really > > >> >> >> didn't care about OTG, we (linux-usb folks) ended up naturally > > >> >> >> referring > > >> >> >> to "non-standard OTG" as "dual-role". Just to avoid confusion. > > >> >> > > > >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention > > >> >> > "OTG" in Linux, right? > > >> >> > > >> >> to avoid confusion with the terminology, yes. With that settled, let's > > >> >> figure out how you can deliver what your marketting guys are asking of > > >> >> you. > > >> >> > > >> > > > >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org > > >> > test. The internal bsp has passed PET test, and formal compliance test > > >> > is on the way (should pass too). > > >> > > > >> > The dual-role and OTG compliance use the same zImage, but different > > >> > dtb. > > >> > > >> okay, that's good to know. Now, the question really is: considering we > > >> only have one user for this generic OTG FSM layer, do we really need to > > >> make it generic at all? I mean, just look at how invasive a change that > > >> is. > > > > > > If the chipidea is the only user for this roger's framework, I don't > > > think it is necessary. In fact, Roger introduces this framework, and > > > the first user is dwc3, we think it can be used for others. Let's > > > > Right, we need to look at the history of dwc3 to figure out why the > > conclusion that dwc3 needs this was made. > > > > Roger started working on this framework when Power on Reset section of > > databook had some details which weren't always clear and, for safety, we > > always had reset asserted for a really long time. It was so long (about > > 400 ms) that resetting dwc3 for each role swap was just too much. > > > > Coupled with that, the OTG chapter wasn't very clear either on > > expections from Host and Peripheral side initialization in OTG/DRD > > systems. > > > > More recent version of dwc3 databook have a much better description of > > how and which reset bits _must_ be asserted and which shouldn't be > > touched unless it's for debugging purposes. When I implemented that, our > > ->probe() went from 400ms down to about 50us. > > > > Coupled with that, the OTG chapter also became a lot clearer to the > > point that it states you just don't initialize anything other than the > > OTG block, and just wait for OTG interrupt to do whatever it is you need > > to do. > > > > This meant that we could actually afford to do full reinitialization of > > dwc3 on role swap (it's now only 50us anyway) and we knew how to swap > > roles properly. > > > > (The reason for needing soft-reset during role swap is kinda long. But > > in summary dwc3 shadows register writes to both host and peripheral > > sides) > > > > > just discuss if it is necessary for dual-role switch. > > > > fair. However, if we have a single user we don't have a Generic > > layer. There's not enough variance to come up with truly generic > > architecture for this. > > > > -- > > I have put some points in my last reply [1], I summery it here to > see if a generic framework is deserved or not? > > 1. If there are some parts we can use during the role switch > - The common start/stop host and peripheral operation > eg, when switch from host to peripheral, all drivers can use > usb_remove_hcd to finish it. > - A common workqueue to handle vbus and id event > - sysfs for role switch > > 2. Does a mux driver can do it well? Yoshihiro, here we need your > point. The main point is if we need to call USB API to change > roles (eg, usb_remove_hcd) dur
Re: Documenting ptrace access mode checking
Hi Jann, Thanks for your further review. Follow-up of one point below. On 06/23/2016 12:44 AM, Jann Horn wrote: On Wed, Jun 22, 2016 at 09:21:29PM +0200, Michael Kerrisk (man-pages) wrote: On 06/21/2016 10:55 PM, Jann Horn wrote: On Tue, Jun 21, 2016 at 11:41:16AM +0200, Michael Kerrisk (man-pages) wrote: [...] The algorithm employed for ptrace access mode checking deter‐ mines whether the calling process is allowed to perform the corresponding action on the target process, as follows: 1. If the calling thread and the target thread are in the same thread group, access is always allowed. 2. If the access mode specifies PTRACE_MODE_FSCREDS, then for the check in the next step, employ the caller's filesystem user ID and group ID (see credentials(7)); otherwise (the access mode specifies PTRACE_MODE_REALCREDS, so) use the caller's real user ID and group ID. Might want to add a "for historical reasons" or so here. Can you be a little more precise about "here", and maybe tell me why you think it helps? I'm not sure, but it might be a good idea to add something like this at the end of 2.: "(Most other APIs that check one of the caller's UIDs use the effective one. This API uses the real UID instead for historical reasons.)" In my opinion, it is inconsistent to use the real UID/GID here, the effective one would be more appropriate. But since the existing code uses the real UID/GID and that's not a security issue for existing users of the ptrace API, this wasn't changed when I added the REALCREDS/FSCREDS distinction. I think that for a reader, it might help to point out that in most cases, when a process is the subject in an access check, its effective UID/GID are used, and this is (together with kill()) an exception to that rule. But you're the expert on writing documentation, if you think that that's too much detail / confusing here, it probably is. Okay -- got it now, I think. I made this text: 2. If the access mode specifies PTRACE_MODE_FSCREDS, then, for the check in the next step, employ the caller's filesystem UID and GID. (As noted in credentials(7), the filesystem UID and GID almost always have the same values as the cor‐ responding effective IDs.) Otherwise, the access mode specifies PTRACE_MODE_REALCREDS, so use the caller's real UID and GID for the checks in the next step. (Most APIs that check the caller's UID and GID use the effective IDs. For historical reasons, the PTRACE_MODE_REALCREDS check uses the real IDs instead.) [...] Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH 4/5] gpio: of: remove of_gpiochip_and_xlate() and struct gg_data
On Tue, Jun 14, 2016 at 12:07 PM, Masahiro Yamada wrote: > The usage of gpiochip_find(&gg_data, of_gpiochip_and_xlate) is odd. > > Usually gpiochip_find() is used to find a gpio_chip. Here, however, > the return value from gpiochip_find() is just discarded. Instead, > gpiochip_find(&gg_data, of_gpiochip_and_xlate) is called for the > side-effect of the match function. > > The match function, of_gpiochip_find_and_xlate(), fills the given > struct gg_data, but a match function should be simply called to > judge the matching. > > This commit fixes this distortion and makes the code more readable. > Remove of_gpiochip_find_and_xlate() and struct gg_data. Instead, > this adds a very simple helper function of_find_gpiochip_by_node(). > Now, of_get_named_gpiod_flags() is implemented more straight-forward. > > Signed-off-by: Masahiro Yamada Excellent patch, this always confused me too. Now I understand the code. Patch applied. Yours, Linus Walleij
Re: [PATCH 5/5] gpio: of: factor out common code to a new helper function
On Tue, Jun 14, 2016 at 12:07 PM, Masahiro Yamada wrote: > The conversion from a DT spec to struct gpio_desc is common between > of_get_named_gpiod_flags() and of_parse_own_gpio(). Factor out the > common code to a new helper, of_xlate_and_get_gpiod_flags(). > > Signed-off-by: Masahiro Yamada Patch applied. Yours, Linus Walleij
RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core
Hi Roger-san, < snip > > commit 11c011a5e777c83819078a18672543f04482b3ec > Author: Srinivas Kandagatla > Date: Thu May 19 11:12:56 2016 +0100 > > usb: echi-hcd: Add ehci_setup check before echi_shutdown > > > > In some cases, the USB code (gadget/hcd->start/stop) needs to be called > during the role swap. For example, if you have mux driver, you may > need to call usb_remove_hcd when ID from 0 to 1. Without Roger's > framework, > how can we do that? > >>> > >>> You don't really need to remove the gadget. Just mask its interrupts and > >>> ignore any calls to any gadget_driver ops, right? Likewise for > >>> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from > >>> the point of view of dwc3, it's simpler to unregister the platform > >>> device we create for xhci-plat.c. I need no changes in XHCI to do that > >>> and driver model will make sure to call xhci-plat's ->remove() which > >>> will handle everything for me correctly. > >>> > >> > >> I admit it can do in a IP driver, eg both host and peripheral for the > >> single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit > >> or what else for HCD at mux driver? > > > > dwc3's OTG block has control of that, however, what I'll do is > > platform_device_del() xhci-plat's device. Not one line changes inside > > XHCI. > > > > Let's talk about how non dwc3 based platforms can get it done. > > Yoshihiro-san, could you please share your platform requirements from > dual-role > perspective? My platform requirements about dual-role are: - Initial settings of all host, gadget and OTG IP registers are needed before enters [AB]-device recognition procedure. - In the recognition procedures, a software needs: - to check ID pin related register in OTG - to set OTG IP registers to change the role - and then host or gadget can start. - In the disconnect detection procedures, a software needs similar checkings/settings with the recognition. Best regards, Yoshihiro Shimoda > cheers, > -roger
Re: [PATCH 0/5] gpio: refactor of_parse_own_gpio() and of_get_named_gpiod_flags()
On Tue, Jun 14, 2016 at 12:07 PM, Masahiro Yamada wrote: > But, after reading this code around, I thought it was more complex > than needed. So, I decided to clean-up it instead of fix the bug. > > Talking about of_parse_own_gpio(), does it need to call gpiochip_find() > in the first place? > > The caller of this function, of_gpiochip_scan_gpios() already knows the > gpio_chip. I want to make the implementation more straight-forward. Thanks a lot for this patch series, it eases maintenance of the gpiolib OF core a lot, and makes the code size smaller too. I bet it also gives better speed. This is a very valuable contribution from you and Socionext to anyone using GPIO with DT. Yours, Linus Walleij
Re: [PATCH] Disable non-ABI-compliant optimisations for live patching
Hi, On Wed, 22 Jun 2016, Josh Poimboeuf wrote: > On Wed, Jun 22, 2016 at 04:24:41PM +0200, Torsten Duwe wrote: > > Live patching, as we use it, deliberately disrupts the fabric of > > compile units; thus all assumptions a compiler can make about the > > control flow may be invalid. As an example, it could analyse that a > > callee does not touch a caller-saved register at all, so why waste > > memory bandwidth saving it? The register allocations for the live > > patch replacement function may however be quite different. But this exact situation should not be possible. Ftrace stub should (and it does on x86_64) save the caller-saved registers for us. Otherwise we would have seen problems with kGraft already. > > Starting with this example, disable all compiler optimisations that > > do not strictly comply with the established calling conventions. It think it is too rough and I'd like to avoid it if possible. > > Signed-off-by: Torsten Duwe > > --- > > > > Working on the arm64 ftrace-with-regs/livepatch, it struck me that > > this is a general problem: with live patching, certain optimisations > > must be switched off for all architectures, the new(?) IPA register > > allocator in gcc6 is only one example. We should tackle this > > well before it bites us. > > > > Torsten > > I think this is a good idea. While we're at it, should we also disable > some of the other IPA options? These sound especially problematic: > > -fipa-sra >Perform interprocedural scalar replacement of aggregates, removal of >unused parameters and replacement of parameters passed by reference >by parameters passed by value. Yes, this changes ABI. There are generally two different situations we need to solve in kGraft. 1. A to-be-patched function is isra-optimized, then its caller functions are patched. 2. As we don't use relocations in kGraft yet we need to call kallsyms on every unexported function. If such function is isra-optimized it is easier and safer to put it in the very kGraft patch. This could surely be avoided if one can prove that the new patching function is optimized in the same way by gcc. > -fipa-cp >Perform interprocedural constant propagation. This optimization >analyzes the program to determine when values passed to functions are >constants and then optimizes accordingly. This optimization can >substantially increase performance if the application has constants >passed to functions. This is the same situation as isra, I think. > -fipa-icf >Perform Identical Code Folding for functions and read-only variables. >The optimization reduces code size and may disturb unwind stacks by >replacing a function by equivalent one with a different name. The >optimization works more effectively with link time optimization >enabled. I haven't met this one yet since we don't have it enabled in SLES as of now. Could be problem... Regards, Miroslav > > > > --- > > Makefile | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/Makefile b/Makefile > > index b409076..424d2e6 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -743,6 +743,13 @@ KBUILD_CFLAGS += $(call cc-option, > > -femit-struct-debug-baseonly) \ > >$(call cc-option,-fno-var-tracking) > > endif > > > > +ifdef CONFIG_LIVEPATCH > > +# The compiler might generate ABI "shortcuts" to speed up the code, > > +# making assumptions which are no longer valid when live patching > > +# is enabled. Disable all of them. > > +KBUILD_CFLAGS += $(call cc-option,-fno-ipa-ra) > > +endif > > + > > ifdef CONFIG_FUNCTION_TRACER > > ifndef CC_FLAGS_FTRACE > > CC_FLAGS_FTRACE := -pg > > -- > > 2.6.6 > > > > -- > Josh > -- > To unsubscribe from this list: send the line "unsubscribe live-patching" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH v3 0/3] acpi/pmic: add opregion driver for Intel BXT WhiskeyCove PMIC
This series modifies the pen function signature to take bit field and adds a new opregion driver for Intel BXT WhiskeyCove PMIC. It also adds support for PMIC regs operation region. Yegnesh Iyer (1): acpi: pmic: Modifying the pen function signature to take bit field Ajay Thomas (1): acpi: pmic: Add opregion driver for Intel BXT WhiskeyCove PMIC Chandra Sekhar Anagani (1): acpi: pmic: Add support for PMIC regs operation region drivers/acpi/pmic/intel_pmic.c | 87 +++-- drivers/acpi/pmic/intel_pmic.h | 11 ++-- drivers/acpi/pmic/intel_pmic_crc.c | 5 +++-- drivers/acpi/Kconfig | 6 + drivers/acpi/Makefile| 1 + drivers/acpi/pmic/intel_pmic_bxtwc.c |449 +++ 6 files changed, 559 insertions(+), 10 deletions(-) create mode 100644 drivers/acpi/pmic/intel_pmic_bxtwc.c -- 1.9.1
[PATCH] extcon: Check for incorrect connection type in notifier register
If we call extcon_register_notifier() with the wrong cable type, it blows up with an oops instead of returning an error code. Let's be nice and fail gracefully given that the consumer might not know if the cable is supported by the extcon provider. Signed-off-by: Stephen Boyd --- drivers/extcon/extcon.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c index 21a123cadf78..161acb826334 100644 --- a/drivers/extcon/extcon.c +++ b/drivers/extcon/extcon.c @@ -586,6 +586,8 @@ int extcon_register_notifier(struct extcon_dev *edev, unsigned int id, return -EINVAL; idx = find_cable_index_by_id(edev, id); + if (idx < 0) + return idx; spin_lock_irqsave(&edev->lock, flags); ret = raw_notifier_chain_register(&edev->nh[idx], nb); @@ -611,6 +613,8 @@ int extcon_unregister_notifier(struct extcon_dev *edev, unsigned int id, return -EINVAL; idx = find_cable_index_by_id(edev, id); + if (idx < 0) + return idx; spin_lock_irqsave(&edev->lock, flags); ret = raw_notifier_chain_unregister(&edev->nh[idx], nb); -- 2.9.0.rc2.8.ga28705d
Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver
Hi CK,
On Thu, 2016-06-23 at 14:03 +0800, CK Hu wrote:
> Hi, HS:
>
> On Mon, 2016-05-30 at 11:19 +0800, HS Liao wrote:
> [...]
>
> > +
> > +/* events for CMDQ and display */
> > +enum cmdq_event {
> > + /* Display start of frame(SOF) events */
> > + CMDQ_EVENT_DISP_OVL0_SOF = 11,
> > + CMDQ_EVENT_DISP_OVL1_SOF = 12,
> > + CMDQ_EVENT_DISP_RDMA0_SOF = 13,
> > + CMDQ_EVENT_DISP_RDMA1_SOF = 14,
> > + CMDQ_EVENT_DISP_RDMA2_SOF = 15,
> > + CMDQ_EVENT_DISP_WDMA0_SOF = 16,
> > + CMDQ_EVENT_DISP_WDMA1_SOF = 17,
> > + /* Display end of frame(EOF) events */
> > + CMDQ_EVENT_DISP_OVL0_EOF = 39,
> > + CMDQ_EVENT_DISP_OVL1_EOF = 40,
> > + CMDQ_EVENT_DISP_RDMA0_EOF = 41,
> > + CMDQ_EVENT_DISP_RDMA1_EOF = 42,
> > + CMDQ_EVENT_DISP_RDMA2_EOF = 43,
> > + CMDQ_EVENT_DISP_WDMA0_EOF = 44,
> > + CMDQ_EVENT_DISP_WDMA1_EOF = 45,
> > + /* Mutex end of frame(EOF) events */
> > + CMDQ_EVENT_MUTEX0_STREAM_EOF = 53,
> > + CMDQ_EVENT_MUTEX1_STREAM_EOF = 54,
> > + CMDQ_EVENT_MUTEX2_STREAM_EOF = 55,
> > + CMDQ_EVENT_MUTEX3_STREAM_EOF = 56,
> > + CMDQ_EVENT_MUTEX4_STREAM_EOF = 57,
> > + /* Display underrun events */
> > + CMDQ_EVENT_DISP_RDMA0_UNDERRUN = 63,
> > + CMDQ_EVENT_DISP_RDMA1_UNDERRUN = 64,
> > + CMDQ_EVENT_DISP_RDMA2_UNDERRUN = 65,
> > + /* Keep this at the end of HW events */
> > + CMDQ_MAX_HW_EVENT_COUNT = 260,
> > +};
>
> The value of these symbol is just the GCE-HW-defined value. I think it's
> not appropriate to expose HW-defined value to client. For another SoC
> GCE HW, these definition may change.
Agree.
> One way to solve this problem is to translate symbol to value
> internally. But these events looks like interrupt and the value may vary
> by each SoC, to prevent driver modified frequently, it's better to place
> the value definition in device tree. It may looks like:
>
> mmsys: clock-controller@1400 {
> compatible = "mediatek,mt8173-mmsys";
> mediatek,gce = <&gce>;
> gce-events = <53 54>;
However, client still needs to know the HW-defined value by using
this solution.
> gce-event-names = "MUTEX0_EOF","MUTEX1_EOF";
> }
>
> For cmdq driver, you just need modify interface from
>
> int cmdq_rec_wfe(struct cmdq_rec *rec, enum cmdq_event event)
> int cmdq_rec_clear_event(struct cmdq_rec *rec, enum cmdq_event event)
>
> to
>
> int cmdq_rec_wfe(struct cmdq_rec *rec, u32 event)
> int cmdq_rec_clear_event(struct cmdq_rec *rec, u32 event)
I think an easy way for this issue is just removing HW-defined values
from include/soc/mediatek/cmdq.h (but keeping enum), and then mapping
abstract values into real values in driver.
The benefit of this solution is that we can keep interface and leave SoC
specific code into driver.
What do you think?
> Regards,
> CK
Thanks,
HS
[PATCH v3 1/3] acpi/pmic: modify the pen function signature to take bit field
Issue description: On some pmics, the policy enable for thermal alerts
refers to different bit fields of the same registers, whereas on other
pmics, the policy enable refers to the same bit field on different
registers. Previous implementation did not provide the flexibility for
supporting the first approach.
Solution: Modified the policy enable function to take bit field as well.
The use of bit field is left to the pmic specific opregion driver.
Signed-off-by: Yegnesh Iyer
Signed-off-by: Bin Gao
---
Changes in v3: no change
Changes in v2:
- Fixed subject line.
drivers/acpi/pmic/intel_pmic.c | 13 +++--
drivers/acpi/pmic/intel_pmic.h | 4 ++--
drivers/acpi/pmic/intel_pmic_crc.c | 5 +++--
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index bd772cd..410e96f 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -131,7 +131,7 @@ static int pmic_thermal_aux(struct intel_pmic_opregion
*opregion, int reg,
}
static int pmic_thermal_pen(struct intel_pmic_opregion *opregion, int reg,
- u32 function, u64 *value)
+ int bit, u32 function, u64 *value)
{
struct intel_pmic_opregion_data *d = opregion->data;
struct regmap *regmap = opregion->regmap;
@@ -140,12 +140,12 @@ static int pmic_thermal_pen(struct intel_pmic_opregion
*opregion, int reg,
return -ENXIO;
if (function == ACPI_READ)
- return d->get_policy(regmap, reg, value);
+ return d->get_policy(regmap, reg, bit, value);
if (*value != 0 && *value != 1)
return -EINVAL;
- return d->update_policy(regmap, reg, *value);
+ return d->update_policy(regmap, reg, bit, *value);
}
static bool pmic_thermal_is_temp(int address)
@@ -170,13 +170,13 @@ static acpi_status intel_pmic_thermal_handler(u32
function,
{
struct intel_pmic_opregion *opregion = region_context;
struct intel_pmic_opregion_data *d = opregion->data;
- int reg, result;
+ int reg, bit, result;
if (bits != 32 || !value64)
return AE_BAD_PARAMETER;
result = pmic_get_reg_bit(address, d->thermal_table,
- d->thermal_table_count, ®, NULL);
+ d->thermal_table_count, ®, &bit);
if (result == -ENOENT)
return AE_BAD_PARAMETER;
@@ -187,7 +187,8 @@ static acpi_status intel_pmic_thermal_handler(u32 function,
else if (pmic_thermal_is_aux(address))
result = pmic_thermal_aux(opregion, reg, function, value64);
else if (pmic_thermal_is_pen(address))
- result = pmic_thermal_pen(opregion, reg, function, value64);
+ result = pmic_thermal_pen(opregion, reg, bit,
+ function, value64);
else
result = -EINVAL;
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index d4e90af..e8bfa7b 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -12,8 +12,8 @@ struct intel_pmic_opregion_data {
int (*update_power)(struct regmap *r, int reg, int bit, bool on);
int (*get_raw_temp)(struct regmap *r, int reg);
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
- int (*get_policy)(struct regmap *r, int reg, u64 *value);
- int (*update_policy)(struct regmap *r, int reg, int enable);
+ int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
+ int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
struct pmic_table *power_table;
int power_table_count;
struct pmic_table *thermal_table;
diff --git a/drivers/acpi/pmic/intel_pmic_crc.c
b/drivers/acpi/pmic/intel_pmic_crc.c
index fcd1852..d7f1761 100644
--- a/drivers/acpi/pmic/intel_pmic_crc.c
+++ b/drivers/acpi/pmic/intel_pmic_crc.c
@@ -141,7 +141,8 @@ static int intel_crc_pmic_update_aux(struct regmap *regmap,
int reg, int raw)
regmap_update_bits(regmap, reg - 1, 0x3, raw >> 8) ? -EIO : 0;
}
-static int intel_crc_pmic_get_policy(struct regmap *regmap, int reg, u64
*value)
+static int intel_crc_pmic_get_policy(struct regmap *regmap,
+ int reg, int bit, u64 *value)
{
int pen;
@@ -152,7 +153,7 @@ static int intel_crc_pmic_get_policy(struct regmap *regmap,
int reg, u64 *value)
}
static int intel_crc_pmic_update_policy(struct regmap *regmap,
- int reg, int enable)
+ int reg, int bit, int enable)
{
int alert0;
--
1.9.1
Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.
Andrew Pinski writes: > So the question becomes do we care enough about the incompatibles > between AARCH32 and AARCH64 to fix this and go just worry about ILP32 > and LP64? Some armv8 chips do not implement all of armv7, so how relevant is aarch32 on aarch64? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH V4 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga
On 6/23/2016 3:38 AM, Tien Hock Loh wrote:
Hi Peppe,
On Wed, 2016-06-22 at 11:00 +0200, Giuseppe CAVALLARO wrote:
Hello Tien Hock
On 6/21/2016 10:46 AM, th...@altera.com wrote:
From: Tien Hock Loh
This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
the dwmac is set to sgmii
Signed-off-by: Tien Hock Loh
IIUC, you are keeping the two timers w/o looking.
Is there any motivation behind? I had understood you wanted
to review it.
I've merged them into one timer, aneg_link_timer and one timer callback
(that invokes individually the auto_nego_timer_callback and
pcs_link_timer_callback) in the patch. Is that not what you were
expecting?
sorry, it is ok, you added the aneg_link_timer_callback
thx for the changes.
Acked-by: Giuseppe Cavallaro
Let me know
Regards
Peppe
---
v2:
- Refactored the TSE PCS out from the dwmac-socfpga.c file
- Added binding documentation for TSE PCS sgmii adapter
v3:
- Added missing license header for new source files
- Updated tse_pcs.h include headers
- Standardize if statements
v4:
- Reset SGMII adapter on speed change
- Do not enable SGMII adapter if speed is not supported
- On init, if PCS reset fails, do not enable adapter
123
---
.../devicetree/bindings/net/socfpga-dwmac.txt | 19 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +-
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c | 276 +
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h | 36 +++
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 149 +--
5 files changed, 460 insertions(+), 22 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
create mode 100644 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 72d82d6..dd10f2f 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -17,9 +17,26 @@ Required properties:
Optional properties:
altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
DWMAC controller is connected emac splitter.
+phy-mode: The phy mode the ethernet operates in
+altr,sgmii_to_sgmii_converter: phandle to the TSE SGMII converter
+
+This device node has additional phandle dependency, the sgmii converter:
+
+Required properties:
+ - compatible : Should be altr,gmii-to-sgmii-2.0
+ - reg-names : Should be "eth_tse_control_port"
Example:
+gmii_to_sgmii_converter: phy@0x10240 {
+ compatible = "altr,gmii-to-sgmii-2.0";
+ reg = <0x0001 0x0240 0x0008>,
+ <0x0001 0x0200 0x0040>;
+ reg-names = "eth_tse_control_port";
+ clocks = <&sgmii_1_clk_0 &emac1 1 &sgmii_clk_125 &sgmii_clk_125>;
+ clock-names = "tse_pcs_ref_clk_clock_connection", "tse_rx_cdr_refclk";
+};
+
gmac0: ethernet@ff70 {
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
altr,sysmgr-syscon = <&sysmgr 0x60 0>;
@@ -30,4 +47,6 @@ gmac0: ethernet@ff70 {
mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
clocks = <&emac_0_clk>;
clock-names = "stmmaceth";
+ phy-mode = "sgmii";
+ altr,gmii-to-sgmii-converter = <&gmii_to_sgmii_converter>;
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 0fb362d..0ff76e8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_DWMAC_IPQ806X) += dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX)+= dwmac-lpc18xx.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
-obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o
+obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o altr_tse_pcs.o
obj-$(CONFIG_DWMAC_STI)+= dwmac-sti.o
obj-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
obj-$(CONFIG_DWMAC_GENERIC)+= dwmac-generic.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
new file mode 100644
index 000..40bfaac
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
@@ -0,0 +1,276 @@
+/* Copyright Altera Corporation (C) 2016. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2,
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH v3 2/3] acpi/pmic: Add opregion driver for Intel BXT WhiskeyCove PMIC
This patch adds operation region driver for Intel BXT WhiskeyCove
PMIC. The register mapping is done as per the BXT WC data sheet.
Signed-off-by: Ajay Thomas
Signed-off-by: Felipe Balbi
Signed-off-by: Chandra Sekhar Anagani
Signed-off-by: Bin Gao
---
Changes in v3:
- Added regs_read() and regs_write() methods to the
intel_pmic_opregion_data{} structure.
Changs in v2:
- Replaced module_init() with device_initcall().
drivers/acpi/Kconfig | 6 +
drivers/acpi/Makefile| 1 +
drivers/acpi/pmic/intel_pmic.h | 2 +
drivers/acpi/pmic/intel_pmic_bxtwc.c | 449 +++
4 files changed, 458 insertions(+)
create mode 100644 drivers/acpi/pmic/intel_pmic_bxtwc.c
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index b7e2e77..47cb6f6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -519,6 +519,12 @@ config XPOWER_PMIC_OPREGION
help
This config adds ACPI operation region support for XPower AXP288 PMIC.
+config BXT_WC_PMIC_OPREGION
+ bool "ACPI operation region support for BXT WhiskeyCove PMIC"
+ depends on INTEL_SOC_PMIC
+ help
+ This config adds ACPI operation region support for BXT WhiskeyCove
PMIC.
+
endif
endif # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 251ce85..5da9d4b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -99,5 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
+obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
video-objs += acpi_video.o video_detect.o
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index e8bfa7b..2f39ee0 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -12,6 +12,8 @@ struct intel_pmic_opregion_data {
int (*update_power)(struct regmap *r, int reg, int bit, bool on);
int (*get_raw_temp)(struct regmap *r, int reg);
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
+ int (*regs_read)(struct regmap *r, u16 address, unsigned int *value);
+ int (*regs_write)(struct regmap *r, u16 address, unsigned int value);
int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
struct pmic_table *power_table;
diff --git a/drivers/acpi/pmic/intel_pmic_bxtwc.c
b/drivers/acpi/pmic/intel_pmic_bxtwc.c
new file mode 100644
index 000..51d5bcc
--- /dev/null
+++ b/drivers/acpi/pmic/intel_pmic_bxtwc.c
@@ -0,0 +1,449 @@
+/*
+ * intel_pmic_bxtwc.c - Intel BXT WhiskeyCove PMIC operation region driver
+ *
+ * Copyright (C) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "intel_pmic.h"
+
+#define WHISKEY_COVE_ALRT_HIGH_BIT_MASK 0x0F
+#define WHISKEY_COVE_ADC_HIGH_BIT(x) (((x & 0x0F) << 8))
+#define WHISKEY_COVE_ADC_CURSRC(x) (((x & 0xF0) >> 4))
+#define VR_MODE_DISABLED0
+#define VR_MODE_AUTOBIT(0)
+#define VR_MODE_NORMAL BIT(1)
+#define VR_MODE_SWITCH BIT(2)
+#define VR_MODE_ECO (BIT(0)|BIT(1))
+#define VSWITCH2_OUTPUT BIT(5)
+#define VSWITCH1_OUTPUT BIT(4)
+#define VUSBPHY_CHARGE BIT(1)
+
+static struct pmic_table power_table[] = {
+ {
+ .address = 0x0,
+ .reg = 0x63,
+ .bit = VR_MODE_AUTO,
+ }, /* VDD1 -> VDD1CNT */
+ {
+ .address = 0x04,
+ .reg = 0x65,
+ .bit = VR_MODE_AUTO,
+ }, /* VDD2 -> VDD2CNT */
+ {
+ .address = 0x08,
+ .reg = 0x67,
+ .bit = VR_MODE_AUTO,
+ }, /* VDD3 -> VDD3CNT */
+ {
+ .address = 0x0c,
+ .reg = 0x6d,
+ .bit = VR_MODE_AUTO,
+ }, /* VLFX -> VFLEXCNT */
+ {
+ .address = 0x10,
+ .reg = 0x6f,
+ .bit = VR_MODE_NORMAL,
+ }, /* VP1A -> VPROG1ACNT */
+ {
+ .address = 0x14,
+ .reg = 0x70,
+ .bit = VR_MODE_NORMAL,
+ }, /* VP1B -> VPROG1BCNT */
+ {
+ .address = 0x18,
+ .reg = 0x71,
+ .bit = VR_MODE_NORMAL,
+ }, /* VP1C ->
Re: [LKP] [PATCH] x86: fix rdmsr MSR_PLATFORM_INFO unsafe warning in kvm guest
2016-06-23 15:41 GMT+08:00 Wanpeng Li : > Hi Yu， > 2016-06-23 15:37 GMT+08:00 Yu Chen : >> On Thu, Jun 23, 2016 at 3:09 PM, Thomas Gleixner wrote: >>> On Wed, 22 Jun 2016, Wanpeng Li wrote: After commit (fc141535ad8 : "x86 tsc_msr: Extend to include Intel Core >>> >>> Where did you find that commit? It's neither in Linus tree nor in tip. >>> >> It is in Len's tree, we are planing to resend the patchset with Wanpeng's fix >> merged with a credit to him in commit msg, thanks for Wanpeng's effort. >> thanks all. > > I prefer this patch can be applied separately instead of fold into the > bad commit since it shows the issue when access MSR_PLATFORM_INFO in > kvm guest and other guys who want to access MSR_PLATFORM_INFO later > can find the changelog and make better decisions. Thomas, does it make sense to keep separate? Regards, Wanpeng Li
[PATCH] arc: warn only once if DW2_UNWIND is disabled
If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core()
gets called following message gets printed in debug console:
->8---
CONFIG_ARC_DW2_UNWIND needs to be enabled
->8---
That message makes sense if user indeed wants to see a backtrace or
get nice function call-graphs in perf but what if user disabled
unwinder for the purpose? Why pollute his debug console?
So instead we'll warn user about possibly missing feature once and
let him decide if that was what he or she really wanted.
Signed-off-by: Alexey Brodkin
Cc: sta...@vger.kernel.org [3.18+]
---
arch/arc/kernel/stacktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index e0efff1..b9192a6 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -142,7 +142,7 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs
*regs,
* prelogue is setup (callee regs saved and then fp set and not other
* way around
*/
- pr_warn("CONFIG_ARC_DW2_UNWIND needs to be enabled\n");
+ pr_warn_once("CONFIG_ARC_DW2_UNWIND needs to be enabled\n");
return 0;
#endif
--
2.5.5
Re: [PATCH v3] gpio: sch: Fix Oops on module load on Asus Eee PC 1201
On Sat, Jun 18, 2016 at 8:05 PM, Colin Pitrat wrote: > This fixes the issue descirbe in bug 117531 > (https://bugzilla.kernel.org/show_bug.cgi?id=117531). > It's a regression introduced in linux 4.5 that causes a Oops at load of > gpio_sch and prevents powering off the computer. > > The issue is that sch_gpio_reg_set is called in sch_gpio_probe before > gpio_chip data is initialized with the pointer to the sch_gpio struct. As > sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes > the Oops. > > The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and > consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a > sch_gpio struct directly instead of a gpio_chip, which avoids the call to > gpiochip_get_data. > > Thanks Mika for your patience with me :-) > > Signed-off-by: Colin Pitrat Patch applied for fixes with Alex' and Mika's ACK. I will add some stable tags as well. Yours, Linus Walleij
[PATCH v3 3/3] acpi/pmic: Add support for PMIC regs operation region
Broxton platform firmware has defined new customized operation
regions called regs for PMIC chip which is used to handle the
PMIC gpio mainly intended for the TYPE-C VBUS and Orientation.
The intel_pmic_regs structure is created also for this purpose
of handling the PMIC register read and write.
Signed-off-by: Chandra Sekhar Anagani
Signed-off-by: Felipe Balbi
Signed-off-by: Bin Gao
---
Changes in v3: none
Changes in v2: none
drivers/acpi/pmic/intel_pmic.c | 74 +-
drivers/acpi/pmic/intel_pmic.h | 5 +++
2 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index 410e96f..53b7052 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -21,12 +21,14 @@
#define PMIC_POWER_OPREGION_ID 0x8d
#define PMIC_THERMAL_OPREGION_ID 0x8c
+#define PMIC_REGS_OPREGION_ID 0x8f
struct intel_pmic_opregion {
struct mutex lock;
struct acpi_lpat_conversion_table *lpat_table;
struct regmap *regmap;
struct intel_pmic_opregion_data *data;
+ struct pmic_regs_handlerctx;
};
static int pmic_get_reg_bit(int address, struct pmic_table *table,
@@ -204,6 +206,52 @@ static acpi_status intel_pmic_thermal_handler(u32 function,
return AE_OK;
}
+static acpi_status intel_pmic_regs_handler(u32 function,
+ acpi_physical_address address, u32 bits, u64 *value64,
+ void *handler_context, void *region_context)
+{
+ struct intel_pmic_opregion *opregion = region_context;
+ struct intel_pmic_opregion_data *d = opregion->data;
+ int result = 0;
+
+ switch (address) {
+ case 0:
+ return AE_OK;
+ case 1:
+ opregion->ctx.address |= (*value64 & 0xff) << 8;
+ return AE_OK;
+ case 2:
+ opregion->ctx.address |= *value64 & 0xff;
+ return AE_OK;
+ case 3:
+ opregion->ctx.value = *value64 & 0xff;
+ return AE_OK;
+ case 4:
+ if (*value64) {
+ result = d->regs_write(opregion->regmap,
+ opregion->ctx.address,
+ opregion->ctx.value);
+ } else {
+ result = d->regs_read(opregion->regmap,
+ opregion->ctx.address,
+ &opregion->ctx.value);
+ if (result == 0)
+ *value64 = opregion->ctx.value;
+ }
+ memset(&opregion->ctx, 0x00, sizeof(opregion->ctx));
+ }
+
+ if (result < 0) {
+ if (result == -EINVAL)
+ return AE_BAD_PARAMETER;
+ else
+ return AE_ERROR;
+ }
+
+ return AE_OK;
+}
+
+
int intel_pmic_install_opregion_handler(struct device *dev, acpi_handle handle,
struct regmap *regmap,
struct intel_pmic_opregion_data *d)
@@ -227,21 +275,31 @@ int intel_pmic_install_opregion_handler(struct device
*dev, acpi_handle handle,
opregion->lpat_table = acpi_lpat_get_conversion_table(handle);
status = acpi_install_address_space_handler(handle,
- PMIC_POWER_OPREGION_ID,
- intel_pmic_power_handler,
- NULL, opregion);
+ PMIC_POWER_OPREGION_ID,
+ intel_pmic_power_handler,
+ NULL, opregion);
+ if (ACPI_FAILURE(status)) {
+ ret = -ENODEV;
+ goto out_error;
+ }
+
+ status = acpi_install_address_space_handler(handle,
+ PMIC_THERMAL_OPREGION_ID,
+ intel_pmic_thermal_handler,
+ NULL, opregion);
if (ACPI_FAILURE(status)) {
+ acpi_remove_address_space_handler(handle,
+ PMIC_POWER_OPREGION_ID,
+ intel_pmic_power_handler);
ret = -ENODEV;
goto out_error;
}
status = acpi_install_address_space_handler(handle,
- PMIC_THERMAL_OPREGION_ID,
- intel_pmic_thermal_handler,
- NULL, opregion);
+ PMIC_REGS_OPREGION_ID,
+ intel_pmic_regs_handler, NULL,
+ opregion);
if (ACPI_FAILURE(status)) {
- acpi_remove_address_space_handler(handle,
PMIC_POWER_OP
Re: [PATCH 5/5] vmlinux.lds.h: replace config_enabled() with IS_ENABLED()
Hi Andrew, Michal, 2016-06-21 8:20 GMT+09:00 Masahiro Yamada : > 2016-06-21 5:45 GMT+09:00 Michal Marek : >> Dne 14.6.2016 v 07:58 Masahiro Yamada napsal(a): >>> The use of config_enabled() against config options is ambiguous. >>> >>> Now, IS_ENABLED() is implemented purely with macro expansion, so >>> let's replace config_enabled() with IS_ENABLED(). >>> >>> Signed-off-by: Masahiro Yamada >> >> I applied the whole series to kbuild.git#kbuild. >> > > This series was applied by Andrew Morton last week. > > I do not want to double it. Could you drop it? Michal, It is OK. Everything is fine now. Andrew, Thanks a lot for taking care of this! -- Best Regards Masahiro Yamada
Re: [PATCH] gpio: sx150x: Update OF configuration
On Mon, Jun 20, 2016 at 5:57 PM, Rob Herring wrote: > On Fri, Jun 17, 2016 at 11:51:03AM +0200, Neil Armstrong wrote: >> +Optional Properties: >> +- oscio-is-gpo: Boolean, Indicated the oscio pin can be used as additional >> + output gpo port. >> + > >> +- pull-up-ports: Array of port numbers which must have pull-up enabled. >> +- pull-down-ports: Array of port numbers which must have pull-down enabled. >> +- open-drain-ports: Array of port numbers which must be configured as >> open-drain, >> + Push-Pull mode is default. >> +- polarity-invert-ports: Array of port numbers whih port polarity must be >> inverted. > > Seems like these should be done in a common way. > > If not, they all need a vendor prefix. Actually on second look, this takes the sx150 to pin control territory. I am starting to feel like a move to drivers/pinctrl/* might be warranted. Neil you worked on other pin controllers IIRC, do you think it would be much work to make a combined GPIO+pinctrl driver and move this over to drivers/pinctrl? I know refactoring across subsystems can be a pain, but at least I'm maintaining both and happy to help out. Yours, Linus Walleij
Re: [PATCH] mellanox: mlx5: Use logging functions to reduce text ~10k/5%
On Wed, Jun 22, 2016 at 9:23 PM, Joe Perches wrote:
[...]
> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> @@ -1557,3 +1557,37 @@ static void __exit cleanup(void)
>
> module_init(init);
> module_exit(cleanup);
> +
> +void mlx5_core_err(struct mlx5_core_dev *dev, const char *fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, fmt);
> +
> + vaf.fmt = fmt;
> + vaf.va = &args;
> +
> + dev_err(&dev->pdev->dev, "%s:%pS:(pid %d): %pV",
> + dev->priv.name, __builtin_return_address(0), current->pid,
> + &vaf);
> +
> + va_end(args);
> +}
> +
> +void mlx5_core_warn(struct mlx5_core_dev *dev, const char *fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, fmt);
> +
> + vaf.fmt = fmt;
> + vaf.va = &args;
> +
> + dev_warn(&dev->pdev->dev, "%s:%pS:(pid %d): %pV",
> +dev->priv.name, __builtin_return_address(0), current->pid,
> +&vaf);
> +
> + va_end(args);
> +}
Hi Joe,
I like to keep the file organized in a bottom-up fashion. Those
functions need to appear as early as possible in the file, just move
them up to appear after the MACROs defines and static fields
declarations.
Re: [PATCH v1 1/1] MAINTAINERS: belong Documentation/pinctrl.txt properly
On Tue, Jun 21, 2016 at 12:52 AM, Andy Shevchenko wrote: > I'm pretty sure that Documentation/pinctrl.txt would be better maintained by > pinctrl subsystem. > > Signed-off-by: Andy Shevchenko Patch applied. Yours, Linus Walleij
4.4.13: fbcon.ko not loaded on boot: kernel or dracut issue?
Hello, Kernel 4.4.8 works fine. During 4.4.13 boot fbcon.ko is not loaded, thus the monitor goes into sleep until xorg is started. Kernel .config is identical between 4.4.8 and 4.4.13. fbcon.ko is built during the kernel compilation. fbcon.ko is in the initramfs for 4.4.13. (verified by unpacking) Downgrading dracut to dracut-041-10.fc22.1.x86_64 did not change this. How can I find the root cause of this issue? Kind regards, Udo
Re: Problem with gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading
Hi Stanislav,
Am Mittwoch, den 22.06.2016, 19:43 +0200 schrieb Stanislav Meduna:
> Hi,
>
> the c04e6e9 patch
>
> gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading
>
> broke display connected to a TQMa53 i.MX53 board. The lines
>
> imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
> imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
>
> are not present anymore and the display shows random lines.
>
> I am using the 4.4.12-rt19+ kernel with some local changes, but
>
> the area of this patch is not touched by either.
>
> I am not sure whether my device tree is at fault (I am not
> an expert here nor did I created the file from scratch) or the patch
> does not take some special case into account. In any case
> reverting the patch solves the problem for me.
It's not your fault. Please update to 4.4.13 or apply commit
310944d148e3 ("drm/imx: Match imx-ipuv3-crtc components using device
node in platform data"). That should fix this issue. See the patch
description for more details.
regards
Philipp
Re: [PATCH] mellanox: mlx5: Use logging functions to reduce text ~10k/5%
On Thu, Jun 23, 2016 at 8:27 AM, Leon Romanovsky wrote: > On Wed, Jun 22, 2016 at 11:23:59AM -0700, Joe Perches wrote: >> The logging macros create a bit of duplicated code/text. >> >> Use specialized functions to reduce the duplication. >> >> (defconfig/x86-64) >> $ size drivers/net/ethernet/mellanox/mlx5/core/built-in.o* >>text data bss dec hex filename >> 178634 2059 16 180709 2c1e5 >> drivers/net/ethernet/mellanox/mlx5/core/built-in.o.new >> 188679 2059 16 190754 2e922 >> drivers/net/ethernet/mellanox/mlx5/core/built-in.o.old >> >> The output changes now do not include line #, >> but do include the function offset. >> >> Signed-off-by: Joe Perches > > As far as I see all these functions are used in error paths, so no > implication on performance is expected. > > And I'm fine with function offsets. > > Saeed, > What do you think? Fine with me, need to fix my comment on functions placement, an your comment on checkpatch.
Re: [PATCH] gpio: sx150x: Update OF configuration
On 06/23/2016 10:08 AM, Linus Walleij wrote: > On Mon, Jun 20, 2016 at 5:57 PM, Rob Herring wrote: >> On Fri, Jun 17, 2016 at 11:51:03AM +0200, Neil Armstrong wrote: > >>> +Optional Properties: >>> +- oscio-is-gpo: Boolean, Indicated the oscio pin can be used as additional >>> + output gpo port. >>> + >> >>> +- pull-up-ports: Array of port numbers which must have pull-up enabled. >>> +- pull-down-ports: Array of port numbers which must have pull-down enabled. >>> +- open-drain-ports: Array of port numbers which must be configured as >>> open-drain, >>> + Push-Pull mode is default. >>> +- polarity-invert-ports: Array of port numbers whih port polarity must be >>> inverted. >> >> Seems like these should be done in a common way. >> >> If not, they all need a vendor prefix. > > Actually on second look, this takes the sx150 to pin control territory. > > I am starting to feel like a move to drivers/pinctrl/* might be warranted. > > Neil you worked on other pin controllers IIRC, do you think it would > be much work to make a combined GPIO+pinctrl driver and move > this over to drivers/pinctrl? > > I know refactoring across subsystems can be a pain, but at least > I'm maintaining both and happy to help out. > > Yours, > Linus Walleij > Hi Linus, Yes, it would be good to have it as a gpio+pinctrl with only pinconf, but it would show the way on how to support external GPIO expanders using the pinctrl framework. But it is quite challenging and needs quite some work, and actually the current state of the driver is that the OF is broken. Would you agree to : - Push the minimal code to make OF work again, at least for 4.7 ? - Engage complete refactoring to transform it in a real gpio+pinctrl driver ? For the dt-bindings properties, I can add the vendor prefixes ASAP. Thanks, Neil
Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length
On Thu, 23 Jun 2016, Zhaoyang Huang wrote: > On 23 June 2016 at 15:01, Thomas Gleixner wrote: > Thomas, I agree with you, I have discussed the modification with the > call back owner. However, I wonder if we can make the idle's framework > to be more precised without the assumption of short CPU_PM_ENTER > callbacks. Thank you! What's the point? To help people who put insanities into the idle code path? Thanks, tglx
Re: [PATCH v1 2/3] drm: Add API for capturing frame CRCs
On Wed, 22 Jun 2016, Daniel Vetter wrote: > On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding > wrote: >> Perhaps another way to avoid that would be to put the two files into a >> separate directory, as in: >> >> /sys/kernel/debug/dri//crtc-/crc/ >> +-- control >> +-- data >> >> That's slightly on the deeply nested side, but on the other hand it >> nicely uses the filesystem for namespacing, which is what filesystems >> are really good at. > > crtc-/crc/(control|data) sounds great. Side note, we should eventually do the same for sink CRCs, but I guess under the connectors. i915 currently has a special cased version for eDP (named "i915_sink_crc_eDP1"...), reading the data from DPCD. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[GIT PULL] UBI/UBIFS fixes for 4.7-rc5
Linus, The following changes since commit c0a1ecb9f4e208f4b75d88fa9669748e3fd705ab: gpio: make library immune to error pointers (2016-06-23 00:29:31 +0200) are available in the git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-4.7-rc5 for you to fetch changes up to 4ac1c17b2044a1b4b2fbed74451947e905fc2992: UBIFS: Implement ->migratepage() (2016-06-23 00:29:53 +0200) This pull requests contains fixes for two critical bugs in UBI and UBIFS: 1. Fixes the possibility of losing data upon a power cut when UBI tries to recover from a write error. 2. Fixes page migration on UBIFS. It turned out that the default page migration function is not suitable for UBIFS. Kirill A. Shutemov (1): UBIFS: Implement ->migratepage() Richard Weinberger (2): ubi: Make recover_peb power cut aware mm: Export migrate_page_move_mapping and migrate_page_copy drivers/mtd/ubi/eba.c | 22 +++--- fs/ubifs/file.c | 24 mm/migrate.c | 2 ++ 3 files changed, 41 insertions(+), 7 deletions(-)
[PATCH] MAINTAINERS: Change FCoE maintainer
Vasu is going to resign from his maintainer role and I'll take over. Signed-off-by: Johannes Thumshirn --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e1b090f..70af8c0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4661,7 +4661,7 @@ S:Maintained F: drivers/staging/fbtft/ FCOE SUBSYSTEM (libfc, libfcoe, fcoe) -M: Vasu Dev +M: Johannes Thumshirn L: fcoe-de...@open-fcoe.org W: www.Open-FCoE.org S: Supported -- 2.8.4
Re: [PATCHv3 1/2] usb: USB Type-C connector class
On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote: > On Wed, 2016-06-22 at 17:38 +0300, Heikki Krogerus wrote: > > On Wed, Jun 22, 2016 at 03:47:03PM +0200, Oliver Neukum wrote: > > > On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote: > > > > If our port is DRD (which would be DRP in the port controller spec), > > > > the supported_power_roles will list: > > > > > > > > device, host > > > > > > > > And the power role, if the port is Source only, the > > > > supported_power_roles will list: > > > > > > > > source > > > > > > > > If the port is Sink only, the supported_power_roles will list: > > > > > > > > sink > > > > > > > > If our port is DRP, the supported_power_roles will list: > > > > > > > > source, sink > > > > > > > > What is there that is missing? We are able to express all the types of > > > > "Roles Supported" that the DEVICE_CAPABILITIES define, no? > > > > > > No, because these are distinct in time. Some ports are DRP so they > > > support > > > > > > device, host > > > > > > at the same time. Some ports can be switched between DFP and UFP > > > they then either support host or device. But you lose the information > > > that the ports can be switched. > > > > You can't ever be host and device at the same time. Just like you > > can't ever be source and sink at the same time. > > True, but you can be able to become host and device at the same time. No you can't.. > That is the purpose of a DRP port. No it's not. DRP means a port that can operate as _either_ Source (host) or Sink (device), but not at the same time.. > And you can be able to become a host and be able to become a device. > But not at the same time. These ports are switchable. > > The current API cannot express the difference. I think you have misunderstood something. The only case where the port can be dual-role is if it's set to be DRP. Otherwise it's Source only OR Sink only. The "Role Supported" bits only tell us how we can program for example the ROLE_CONTROL registers. I guess the "Roles Supported" bits in DEVICE_CAPABILITIES are not explained properly, so let's go over them here: 000b = Source _or_ Sink only 001b = Source only 010b = Sink only 011b = Sink only with support for autonomously detected accessory modes 100b = DRP only, and this I believe mean we can not program the port to be Sink only or Source only 101b = Source only OR Sink only OR DRP, plus ability to detect accessories and I guess also cables autonomously 110b = Source only OR Sink only OR DRP So where the spec lists "Source, Sink", it actually should have said "Source only OR Sink only". But you still have only the following options for a port: 1) Source only (host) 2) Sink only (device) 3) DRP (device, host) Thanks, -- heikki
Re: [RESEND PATCH v2 2/5] pwm: omap-dmtimer: Allow for setting dmtimer clock source
On Wed, Jun 22, 2016 at 10:22:18PM +0300, Ivaylo Dimitrov wrote: > OMAP GP timers can have different input clocks that allow different PWM > frequencies. However, there is no other way of setting the clock source but > through clocks or clock-names properties of the timer itself. This limits > PWM functionality to only the frequencies allowed by the particular clock > source. Allowing setting the clock source by PWM rather than by timer > allows different PWMs to have different ranges by not hard-wiring the clock > source to the timer. > > Signed-off-by: Ivaylo Dimitrov > Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt | 4 > drivers/pwm/pwm-omap-dmtimer.c | 12 +++- > 2 files changed, 11 insertions(+), 5 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v1 2/3] drm: Add API for capturing frame CRCs
On 23 June 2016 at 10:21, Jani Nikula wrote: > On Wed, 22 Jun 2016, Daniel Vetter wrote: >> On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding >> wrote: >>> Perhaps another way to avoid that would be to put the two files into a >>> separate directory, as in: >>> >>> /sys/kernel/debug/dri//crtc-/crc/ >>> +-- control >>> +-- data >>> >>> That's slightly on the deeply nested side, but on the other hand it >>> nicely uses the filesystem for namespacing, which is what filesystems >>> are really good at. >> >> crtc-/crc/(control|data) sounds great. > > Side note, we should eventually do the same for sink CRCs, but I guess > under the connectors. i915 currently has a special cased version for eDP > (named "i915_sink_crc_eDP1"...), reading the data from DPCD. Was hoping we could just add one more source to this interface to expose those. Regards, Tomeu
Re: [PATCHv3 1/2] usb: USB Type-C connector class
Hi,
On Wed, Jun 22, 2016 at 02:54:28PM -0700, Guenter Roeck wrote:
> Hi,
>
> > +
> > +static void typec_remove_partner(struct typec_port *port)
> > +{
> > + WARN_ON(port->partner->alt_modes);
>
> You are setting partner->alt_modes in typec_register_altmodes(),
> but you don't clear it in typec_unregister_altmodes().
>
> Does this work for you ? I always get the warning when I remove a cable.
Damn it.. I have managed to just ignore the warning.
Yeah, this has to be fixed. Sorry about that.
Thanks,
--
heikki
RE: [PATCH 1/6] virtio-balloon: rework deflate to add page to a list
Ping ...
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Monday, June 13, 2016 5:47 PM
> To: k...@vger.kernel.org
> Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongun.org; linux-
> ker...@vger.kernel.org; m...@redhat.com; Li, Liang Z; Paolo Bonzini; Cornelia
> Huck; Amit Shah
> Subject: [PATCH 1/6] virtio-balloon: rework deflate to add page to a list
>
> will allow faster notifications using a bitmap down the road.
> Now balloon_pfn_to_page() can be removed because it is not used.
>
> Signed-off-by: Liang Li
> Signed-off-by: Michael S. Tsirkin
> Cc: Paolo Bonzini
> Cc: Cornelia Huck
> Cc: Amit Shah
> ---
> drivers/virtio/virtio_balloon.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 476c0e3..8d649a2 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -98,12 +98,6 @@ static u32 page_to_balloon_pfn(struct page *page)
> return pfn * VIRTIO_BALLOON_PAGES_PER_PAGE; }
>
> -static struct page *balloon_pfn_to_page(u32 pfn) -{
> - BUG_ON(pfn % VIRTIO_BALLOON_PAGES_PER_PAGE);
> - return pfn_to_page(pfn / VIRTIO_BALLOON_PAGES_PER_PAGE);
> -}
> -
> static void balloon_ack(struct virtqueue *vq) {
> struct virtio_balloon *vb = vq->vdev->priv; @@ -176,18 +170,16 @@
> static unsigned fill_balloon(struct virtio_balloon *vb, size_t num)
> return num_allocated_pages;
> }
>
> -static void release_pages_balloon(struct virtio_balloon *vb)
> +static void release_pages_balloon(struct virtio_balloon *vb,
> + struct list_head *pages)
> {
> - unsigned int i;
> - struct page *page;
> + struct page *page, *next;
>
> - /* Find pfns pointing at start of each page, get pages and free them.
> */
> - for (i = 0; i < vb->num_pfns; i +=
> VIRTIO_BALLOON_PAGES_PER_PAGE) {
> - page = balloon_pfn_to_page(virtio32_to_cpu(vb->vdev,
> -vb->pfns[i]));
> + list_for_each_entry_safe(page, next, pages, lru) {
> if (!virtio_has_feature(vb->vdev,
>
> VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> adjust_managed_page_count(page, 1);
> + list_del(&page->lru);
> put_page(page); /* balloon reference */
> }
> }
> @@ -197,6 +189,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb,
> size_t num)
> unsigned num_freed_pages;
> struct page *page;
> struct balloon_dev_info *vb_dev_info = &vb->vb_dev_info;
> + LIST_HEAD(pages);
>
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
> @@ -208,6 +201,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb,
> size_t num)
> if (!page)
> break;
> set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
> + list_add(&page->lru, &pages);
> vb->num_pages -= VIRTIO_BALLOON_PAGES_PER_PAGE;
> }
>
> @@ -219,7 +213,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb,
> size_t num)
>*/
> if (vb->num_pfns != 0)
> tell_host(vb, vb->deflate_vq);
> - release_pages_balloon(vb);
> + release_pages_balloon(vb, &pages);
> mutex_unlock(&vb->balloon_lock);
> return num_freed_pages;
> }
> --
> 1.9.1
[tip:irq/core] irqdomain: Fix disposal of mappings for interrupt hierarchies
Commit-ID: d16dcd3d18759eb955e0325572d07457f93494f5
Gitweb: http://git.kernel.org/tip/d16dcd3d18759eb955e0325572d07457f93494f5
Author: Jon Hunter
AuthorDate: Tue, 21 Jun 2016 10:23:22 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 23 Jun 2016 10:21:06 +0200
irqdomain: Fix disposal of mappings for interrupt hierarchies
The function irq_create_of_mapping() is used to create an interrupt
mapping. However, depending on whether the irqdomain, to which the
interrupt belongs, is part of a hierarchy, determines whether the
mapping is created via calling irq_domain_alloc_irqs() or
irq_create_mapping().
To dispose of the interrupt mapping, drivers call irq_dispose_mapping().
However, this function does not check to see if the irqdomain is part
of a hierarchy or not and simply assumes that it was mapped via calling
irq_create_mapping() so calls irq_domain_disassociate() to unmap the
interrupt.
Fix this by checking to see if the irqdomain is part of a hierarchy and
if so call irq_domain_free_irqs() to free/unmap the interrupt.
Signed-off-by: Jon Hunter
Cc: Marc Zyngier
Cc: Jiang Liu
Link:
http://lkml.kernel.org/r/1466501002-16368-1-git-send-email-jonath...@nvidia.com
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdomain.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index caa6a63..5d89d72 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -680,8 +680,12 @@ void irq_dispose_mapping(unsigned int virq)
if (WARN_ON(domain == NULL))
return;
- irq_domain_disassociate(domain, virq);
- irq_free_desc(virq);
+ if (irq_domain_is_hierarchy(domain)) {
+ irq_domain_free_irqs(virq, 1);
+ } else {
+ irq_domain_disassociate(domain, virq);
+ irq_free_desc(virq);
+ }
}
EXPORT_SYMBOL_GPL(irq_dispose_mapping);
random: negative entropy/overflow: pool input count -40000
Hello,
The following program triggers a WARNING. Looks like some missing user
input validation.
random: negative entropy/overflow: pool input count -4
[ cut here ]
WARNING: CPU: 3 PID: 6828 at drivers/char/random.c:670[< none
>] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
Modules linked in:
CPU: 3 PID: 6828 Comm: a.out Not tainted 4.7.0-rc4+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
880b58e0 88005dd9fcb0 82cc838f 87158b40
fbfff1016b1c 87158b40
83283dae 0009 88005dd9fcf8 8136d27f
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x12e/0x18f lib/dump_stack.c:51
[] __warn+0x19f/0x1e0 kernel/panic.c:516
[] warn_slowpath_null+0x2c/0x40 kernel/panic.c:551
[] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
[< inline >] credit_entropy_bits_safe drivers/char/random.c:734
[] random_ioctl+0x21d/0x250 drivers/char/random.c:1546
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
[< inline >] SYSC_ioctl fs/ioctl.c:689
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
[] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
---[ end trace 5d4902b2ba842f1f ]---
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
int main() {
int fd = open("/dev/random", O_RDWR);
int val = -5000;
ioctl(fd, RNDADDTOENTCNT, &val);
return 0;
}
On commit 67016f6cdfd079e632bbc49e33178b2d558c120a (Jun 20).
RE: [PATCH 0/6] Fast balloon & fast live migration
Any comments? Liang > -Original Message- > From: Li, Liang Z > Sent: Monday, June 13, 2016 5:47 PM > To: k...@vger.kernel.org > Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongun.org; linux- > ker...@vger.kernel.org; m...@redhat.com; Li, Liang Z > Subject: [PATCH 0/6] Fast balloon & fast live migration > > The implementation of the current virtio-balloon is not very efficient, bellow > is test result of time spends on inflating the balloon to 3GB of a 4GB idle > guest: > > a. allocating pages (6.5%, 103ms) > b. sending PFNs to host (68.3%, 787ms) > c. address translation (6.1%, 96ms) > d. madvise (19%, 300ms) > > It takes about 1577ms for the whole inflating process to complete. > The test shows that the bottle neck is the stage b and stage d. > > If using a bitmap to send the page info instead of the PFNs, we can reduce > the overhead in stage b quite a lot. Furthermore, it's possible to do the > address translation and the madvise with a bulk of pages, instead of the > current page per page way, so the overhead of stage c and stage d can also > be reduced a lot. > > In addition, we can speed up live migration by skipping process guest's free > pages. > > Patch 1 and patch 2 are the kernel side implementation which are intended > to speed up the inflating & deflating process by adding a new feature to the > virtio-balloon device. And now, inflating the balloon to 3GB of a 4GB idle > guest only takes 200ms, it's about 8 times as fast as before. > > > Patch 3 and patch 4 add the cache drop support, now hypervisor can request > the guest to drop it's cache. It's useful before inflating the virtio-balloon > and > before starting live migration. > > Patch 5 and patch 6 save guest's free page information into a page bitmap > and send the bitmap to host through balloon's virt queue. > > Liang Li (6): > virtio-balloon: rework deflate to add page to a list > virtio-balloon: speed up inflate/deflate process > mm:split the drop cache operation into a function > virtio-balloon: add drop cache support > mm: add the related functions to get free page info > virtio-balloon: tell host vm's free page info > > drivers/virtio/virtio_balloon.c | 321 > +++- > fs/drop_caches.c| 22 ++- > include/linux/mm.h | 1 + > include/uapi/linux/virtio_balloon.h | 2 + > mm/page_alloc.c | 40 + > 5 files changed, 339 insertions(+), 47 deletions(-) > > -- > 1.9.1
Re: [LTP] [patch V2 00/20] timer: Refactor the timer wheel
On Wed, 22 Jun 2016, Cyril Hrubis wrote:
> Hi!
> > > rtbox:~ #
> > > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test
> > > Test FAILED: sigtimedwait() did not return in the required time
> > > time_elapsed: 1.197057
> > > ...come on, you can do it...
> > > rtbox:~ #
> > > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test
> > > Test PASSED
> > >
> > > #define ERRORMARGIN 0.1
> > > ...
> > > if ((time_elapsed > SIGTIMEDWAITSEC + ERRORMARGIN)
> > > || (time_elapsed < SIGTIMEDWAITSEC - ERRORMARGIN)) {
> > > printf("Test FAILED: sigtimedwait() did not return in "
> > > "the required time\n");
> > > printf("time_elapsed: %lf\n", time_elapsed);
> > > return PTS_FAIL;
> > > }
> > >
> > > Looks hohum to me, but gripe did arrive with patch set, so you get a note.
> >
> > hohum is a euphemism. That's completely bogus.
> >
> > The only guarantee a syscall with timers has is: timer does not fire early.
>
> While this is true, checking with reasonable error margin works just
> fine 99% of the time. You cannot really test that timer expires, without
> setting arbitrary margin.
Err. You know that the timer expired because sigtimedwait() returns
EAGAIN. And the only thing you can reliably check for is that the timer did
not expired to early. Anything else is guesswork and voodoo programming.
Thanks,
tglx
Re: [PATCH 3/4] uio: introduce devicetree bindings for uio_dmem_genirq
Sorry for jumping-in late ... On Tue, May 24, 2016 at 2:06 AM, Rob Herring wrote: > On Thu, May 19, 2016 at 10:45:56AM +0200, Jan Viktorin wrote: >> Hello Rob, >> >> thank you for your opinion... >> >> On Wed, 18 May 2016 12:01:05 -0500 >> Rob Herring wrote: >> >> > On Tue, May 17, 2016 at 11:22:19AM +0200, Jan Viktorin wrote: >> > > Signed-off-by: Jan Viktorin >> > > --- >> > > .../devicetree/bindings/uio/uio_dmem_genirq.txt | 16 >> > > >> > > 1 file changed, 16 insertions(+) >> > > create mode 100644 >> > > Documentation/devicetree/bindings/uio/uio_dmem_genirq.txt >> > >> > DT describes h/w. UIO is not a h/w block, so this does not belong in DT. >> > A UIO vs. kernel driver is purely a kernel decision which shouldn't >> > require a DT change. >> >> I mostly agree and I don't say this is the very best solution... however, >> it is quite a straightforward one. >> >> > >> > The properties should be part of match data for a compatible string that >> >> True. But in case of probing from DT, where can I obtain those match data >> from? I have to patch the kernel... and that is what I tried to avoid. > > spi-dev is a similar situation and we put compatible strings (and > therefore potentially match data) in the kernel. > >> With this patch set, you only modify your current device-tree (extend the >> appropriate devices by "uio,...") and reboot with this new one. > > Generally speaking changing your kernel is as easy or easier than > changing the DT. > > Rebooting is not a very good choice either when it could easily be a > module unload/reload instead. We can pass name of the DT attributes as kernel parameters. This will not require any DT bindings change. The main advantage in having DT attributes for UIO dmem is that we can have two different UIO dmem DT nodes with different number of dynamic regions. In fact, we can pass UIO dmem compatible string also as kernel parameter just like UIO pdrv driver but this feature is missing current UIO dmem driver. > >> > needs them set. Or if they can be defined in a way that is actually a >> > property of the h/w, then it would be acceptible. You'd still need to >> > define compatible strings that the properties apply to. >> >> If you look at uio_pdrv_genirq you can see that it has already been extended >> by >> the module param "of_id". I.e. it is possible to specify the compatible >> property >> it would match when doing insmod. So, it is possible to bind it to any >> platform >> device described by the device tree. And thus, there is no way how to define >> a >> list of compatible strings for it... (quite a long list, isn't it?) >> >> The same (of_id) can be done for uio_dmem_genirq, however, there is no way >> how to >> specify the amount of dynamic memory to be used for a specific device. For >> me, it >> makes sense to use DT to obtain those two properties saying "those devices >> would >> use this amount of memory and not more". >> >> Perhaps, another module param is a way to go here. Something like >> of_dmem_count=2, >> of_dmem_sizes=32k. Less flexible solution, however, if it is acceptable I'll >> rewrite >> the current one. > > No issue with doing that, though they are not OF parameters at that > point. > > Rob > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Regards, Anup
RE: [PATCH 1/6] virtio-balloon: rework deflate to add page to a list
Hi Michael,
Could you help to review this patch set and give some comments when you have
time?
My work is blocked here.
Thanks !
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Monday, June 13, 2016 5:47 PM
> To: k...@vger.kernel.org
> Cc: virtio-...@lists.oasis-open.org; qemu-de...@nongun.org; linux-
> ker...@vger.kernel.org; m...@redhat.com; Li, Liang Z; Paolo Bonzini; Cornelia
> Huck; Amit Shah
> Subject: [PATCH 1/6] virtio-balloon: rework deflate to add page to a list
>
> will allow faster notifications using a bitmap down the road.
> Now balloon_pfn_to_page() can be removed because it is not used.
>
> Signed-off-by: Liang Li
> Signed-off-by: Michael S. Tsirkin
> Cc: Paolo Bonzini
> Cc: Cornelia Huck
> Cc: Amit Shah
> ---
> drivers/virtio/virtio_balloon.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 476c0e3..8d649a2 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -98,12 +98,6 @@ static u32 page_to_balloon_pfn(struct page *page)
> return pfn * VIRTIO_BALLOON_PAGES_PER_PAGE; }
>
> -static struct page *balloon_pfn_to_page(u32 pfn) -{
> - BUG_ON(pfn % VIRTIO_BALLOON_PAGES_PER_PAGE);
> - return pfn_to_page(pfn / VIRTIO_BALLOON_PAGES_PER_PAGE);
> -}
> -
> static void balloon_ack(struct virtqueue *vq) {
> struct virtio_balloon *vb = vq->vdev->priv; @@ -176,18 +170,16 @@
> static unsigned fill_balloon(struct virtio_balloon *vb, size_t num)
> return num_allocated_pages;
> }
>
> -static void release_pages_balloon(struct virtio_balloon *vb)
> +static void release_pages_balloon(struct virtio_balloon *vb,
> + struct list_head *pages)
> {
> - unsigned int i;
> - struct page *page;
> + struct page *page, *next;
>
> - /* Find pfns pointing at start of each page, get pages and free them.
> */
> - for (i = 0; i < vb->num_pfns; i +=
> VIRTIO_BALLOON_PAGES_PER_PAGE) {
> - page = balloon_pfn_to_page(virtio32_to_cpu(vb->vdev,
> -vb->pfns[i]));
> + list_for_each_entry_safe(page, next, pages, lru) {
> if (!virtio_has_feature(vb->vdev,
>
> VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> adjust_managed_page_count(page, 1);
> + list_del(&page->lru);
> put_page(page); /* balloon reference */
> }
> }
> @@ -197,6 +189,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb,
> size_t num)
> unsigned num_freed_pages;
> struct page *page;
> struct balloon_dev_info *vb_dev_info = &vb->vb_dev_info;
> + LIST_HEAD(pages);
>
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
> @@ -208,6 +201,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb,
> size_t num)
> if (!page)
> break;
> set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
> + list_add(&page->lru, &pages);
> vb->num_pages -= VIRTIO_BALLOON_PAGES_PER_PAGE;
> }
>
> @@ -219,7 +213,7 @@ static unsigned leak_balloon(struct virtio_balloon *vb,
> size_t num)
>*/
> if (vb->num_pfns != 0)
> tell_host(vb, vb->deflate_vq);
> - release_pages_balloon(vb);
> + release_pages_balloon(vb, &pages);
> mutex_unlock(&vb->balloon_lock);
> return num_freed_pages;
> }
> --
> 1.9.1
[PATCH 2/2] HID: multitouch: enable palm rejection for Windows Precision Touchpad
The usage Confidence is mandary to Windows Precision Touchpad devices. If
it is examined in input_mapping on a WIndows Precision Touchpad, a new add
quirk MT_QUIRK_CONFIDENCE desgned for such devices will be applied to the
device. A touch with the confidence bit is not set is determined as
invalid.
Tested on Dell XPS13 9343
Signed-off-by: Allen Hung
---
drivers/hid/hid-multitouch.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 4ef7006..fb6f1f4 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -61,6 +61,7 @@ MODULE_LICENSE("GPL");
#define MT_QUIRK_ALWAYS_VALID (1 << 4)
#define MT_QUIRK_VALID_IS_INRANGE (1 << 5)
#define MT_QUIRK_VALID_IS_CONFIDENCE (1 << 6)
+#define MT_QUIRK_CONFIDENCE(1 << 7)
#define MT_QUIRK_SLOT_IS_CONTACTID_MINUS_ONE (1 << 8)
#define MT_QUIRK_NO_AREA (1 << 9)
#define MT_QUIRK_IGNORE_DUPLICATES (1 << 10)
@@ -78,6 +79,7 @@ struct mt_slot {
__s32 contactid;/* the device ContactID assigned to this slot */
bool touch_state; /* is the touch valid? */
bool inrange_state; /* is the finger in proximity of the sensor? */
+ bool confidence_state; /* is the touch made by a finger? */
};
struct mt_class {
@@ -502,6 +504,9 @@ static int mt_touch_input_mapping(struct hid_device *hdev,
struct hid_input *hi,
mt_store_field(usage, td, hi);
return 1;
case HID_DG_CONFIDENCE:
+ if (cls->name == MT_CLS_WIN_8 &&
+ field->application == HID_DG_TOUCHPAD)
+ cls->quirks |= MT_QUIRK_CONFIDENCE;
mt_store_field(usage, td, hi);
return 1;
case HID_DG_TIPSWITCH:
@@ -614,6 +619,7 @@ static void mt_complete_slot(struct mt_device *td, struct
input_dev *input)
return;
if (td->curvalid || (td->mtclass.quirks & MT_QUIRK_ALWAYS_VALID)) {
+ int active;
int slotnum = mt_compute_slot(td, input);
struct mt_slot *s = &td->curdata;
struct input_mt *mt = input->mt;
@@ -628,10 +634,14 @@ static void mt_complete_slot(struct mt_device *td, struct
input_dev *input)
return;
}
+ if (!(td->mtclass.quirks & MT_QUIRK_CONFIDENCE))
+ s->confidence_state = 1;
+ active = (s->touch_state || s->inrange_state) &&
+ s->confidence_state;
+
input_mt_slot(input, slotnum);
- input_mt_report_slot_state(input, MT_TOOL_FINGER,
- s->touch_state || s->inrange_state);
- if (s->touch_state || s->inrange_state) {
+ input_mt_report_slot_state(input, MT_TOOL_FINGER, active);
+ if (active) {
/* this finger is in proximity of the sensor */
int wide = (s->w > s->h);
/* divided by two to match visual scale of touch */
@@ -696,6 +706,8 @@ static void mt_process_mt_event(struct hid_device *hid,
struct hid_field *field,
td->curdata.touch_state = value;
break;
case HID_DG_CONFIDENCE:
+ if (quirks & MT_QUIRK_CONFIDENCE)
+ td->curdata.confidence_state = value;
if (quirks & MT_QUIRK_VALID_IS_CONFIDENCE)
td->curvalid = value;
break;
--
2.7.4
[PATCH 1/2] Revert "HID: multitouch: enable palm rejection if device implements confidence usage"
This reverts commit 25a84db15b3f ("HID: multitouch: enable palm rejection
if device implements confidence usage")
The commit enables palm rejection for Win8 Precision Touchpad devices but
the quirk MT_QUIRK_VALID_IS_CONFIDENCE it is using is not working very
properly. This quirk is originally designed for some WIn7 touchscreens. Use
of this for a Win8 Precision Touchpad will cause unexpected pointer jumping
problem.
Signed-off-by: Allen Hung
---
drivers/hid/hid-multitouch.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 95b7d61..4ef7006 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -502,11 +502,6 @@ static int mt_touch_input_mapping(struct hid_device *hdev,
struct hid_input *hi,
mt_store_field(usage, td, hi);
return 1;
case HID_DG_CONFIDENCE:
- if (cls->name == MT_CLS_WIN_8 &&
- field->application == HID_DG_TOUCHPAD) {
- cls->quirks &= ~MT_QUIRK_ALWAYS_VALID;
- cls->quirks |= MT_QUIRK_VALID_IS_CONFIDENCE;
- }
mt_store_field(usage, td, hi);
return 1;
case HID_DG_TIPSWITCH:
--
2.7.4
Re: [PATCH 1/2] leds: ncp5623: Add device tree binding documentation
Hi Jacek,
On 06/23/2016 09:23 AM, Jacek Anaszewski wrote:
> On 06/22/2016 04:25 PM, Florian Vaussard wrote:
>> Hi Jacek,
>>
>> Le 22. 06. 16 à 10:51, Jacek Anaszewski a écrit :
>>> Hi Florian,
>>>
>>> On 06/22/2016 08:08 AM, Florian Vaussard wrote:
Hi Jacek,
Le 21. 06. 16 à 17:28, Jacek Anaszewski a écrit :
> Hi Florian,
>
> Thanks for the patch. I have two remarks below.
>
> On 06/21/2016 09:29 AM, Florian Vaussard wrote:
>> Add device tree binding documentation for On Semiconductor NCP5623 I2C
>> LED driver. The driver can independently control the PWM of the 3
>> channels with 32 levels of intensity.
>>
>> The current delivered by the current source can be controlled using the
>> led-max-microamp property. In order to control this value, it is also
>> necessary to know the current on the Iref pin, hence the
>> onnn,led-iref-microamp property. It is usually set using an external
>> bias resistor, following Iref = Vref/Rbias with Vref=0.6V.
>>
>> Signed-off-by: Florian Vaussard
>> ---
>> .../devicetree/bindings/leds/leds-ncp5623.txt | 44
>> ++
>> 1 file changed, 44 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/leds/leds-ncp5623.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
>> b/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
>> new file mode 100644
>> index 000..0dc8345
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
>> @@ -0,0 +1,44 @@
>> +* ON Semiconductor - NCP5623 3-Channel LED Driver
>> +
>> +The NCP5623 is a 3-channel I2C LED driver. The brightness of each
>> +channel can be independently set using 32 levels. Each LED is
>> represented
>> +as a sub-node of the device.
>> +
>> +Required properties:
>> + - compatible: Should be "onnn,ncp5623"
>> + - reg: I2C slave address (fixed to 0x38)
>> + - #address-cells: must be 1
>> + - #size-cells: must be 0
>> + - onnn,led-iref-microamp: Current on the Iref pin in microampere
>
> I think that you don't need this property. Just provide the formula for
> calculating led-max-microamp value, similarly as you're doing that in
> the commit message.
>
I am not completely sure to understand your suggestion. So at the end, I
have to
compute the value of the register (let call it 'ILED') that I need to send
to
chip to configure the current source. The formula is:
ILED = 31 - 2400*Iref/led-max-microamp
>>>
>>> led-max-microamp is the maximum current value for given LED.
>>> According to the documentation it can be calculated as follows:
>>>
>>> ILEDmax = Iref * 2400 / (31 - n)
>>>
>>> Since this is global setting for all LEDs, then I'd always set n to 30,
>>> and calculate max_brightness value for each LED separately, basing on
>>> led-max-microamp property value. Effectively, I'm revoking my previous
>>> statement about setting max_brightness to fixed level.
>>>
>>
>> Ok your proposal simplifies a bit the handling. Thus ILEDmax of the current
>> source would be always equal to Iref * 2400 and we use the PWM to limit the
>> current inside the LED. The only downside of this approach is a reduced
>> number
>> of possible PWM steps, thus a limited number of RGB colors.
>
> Yes, but by max_brightness being always 31, lowering led-max-microamp
> results in decreasing the amount of current per brightness level.
> Effectively, a human ability to notice perceived brightness level
> change also decreases then.
>
> In the approach I proposed this limitation is reflected in reduced
> amount of available brightness levels.
>
>> Regarding the DT binding, this would mean something like this:
>>
>> ncp5623@38 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> compatible = "onnn,ncp5623";
>> reg = <0x38>;
>> led-max-microamp = <3>;
>
> Please drop it from here. It doesn't need to be configurable.
> You can hard code this in the driver.
>
It is not user configurable, but it is a hardware configuration imposed by the
bias resistor on the Iref pin (ILEDmax = 2400*Iref = 2400*0.6V/Rbias). So I
cannot hard code it as it can change from one design to another. And I need this
piece of information to compute the maximum allowable PWM ratio.
>>
>> ledr@0 {
>> label = "ncp:power:red";
>> reg = <0>;
>> linux,default-trigger = "default-on";
>> led-max-microamp = <5000>;
>
> Is 5mA the maximum allowed current value for the LEDs on the board
> you're using? Is brightness level change easily noticeable by max
> current set to 5mA and max_brightness set to 31? It would be good
> to empirically check this configuration.
>
No the maximum is 20mA on our board, but limiting to 5mA is safer to avoid
blinding the user :) This RGB led is quite p
Re: [PATCH 16/27] mm: Move page mapped accounting to the node
On Tue, Jun 21, 2016 at 03:32:06PM -0700, Andrew Morton wrote: > On Tue, 21 Jun 2016 15:15:55 +0100 Mel Gorman > wrote: > > > Reclaim makes decisions based on the number of pages that are mapped > > but it's mixing node and zone information. Account NR_FILE_MAPPED and > > NR_ANON_PAGES pages on the node. > > > > Boy, the difference between > > __mod_zone_page_state(page_zone(page), ... > > and > > __mod_node_page_state(page_pgdat(page), ... > > is looking subtle. When and why to use one versus the other. I'm not > seeing any explanation of this in there but haven't yet looked hard. > I'm not sure I see the problem. One applies for zone stats and the other is for node. Granted, care is needed to use the correct one or a random stat is updated instead of the one intended. -- Mel Gorman SUSE Labs
Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length
On 23 June 2016 at 16:18, Thomas Gleixner wrote: > On Thu, 23 Jun 2016, Zhaoyang Huang wrote: >> On 23 June 2016 at 15:01, Thomas Gleixner wrote: >> Thomas, I agree with you, I have discussed the modification with the >> call back owner. However, I wonder if we can make the idle's framework >> to be more precised without the assumption of short CPU_PM_ENTER >> callbacks. Thank you! > > What's the point? To help people who put insanities into the idle code path? > > Thanks, > > tglx > Hi, Thomas. If the entry,exit,min time of one idle state sums up to 500us in some platform, the 100us callback which should be common as caused by cache miss would also generate 20% imprecision. Don't you think it is a case we should deal with?
Re: [PATCH RFC 1/2] rtc/hpet: Factorize hpet_rtc_timer_init()
On Tue, 21 Jun 2016, Pratyush Anand wrote: > This patch factorize hpet_rtc_timer_init(), so that counter can be > initialized before irq is registered. This changelog is useless. It tells what the patch does, but not WHY this is required. Thanks, tglx
Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length
On Thu, 23 Jun 2016, Zhaoyang Huang wrote: > On 23 June 2016 at 16:18, Thomas Gleixner wrote: > > On Thu, 23 Jun 2016, Zhaoyang Huang wrote: > >> On 23 June 2016 at 15:01, Thomas Gleixner wrote: > >> Thomas, I agree with you, I have discussed the modification with the > >> call back owner. However, I wonder if we can make the idle's framework > >> to be more precised without the assumption of short CPU_PM_ENTER > >> callbacks. Thank you! > > > > What's the point? To help people who put insanities into the idle code path? > > > > Thanks, > > > > tglx > > > Hi, Thomas. If the entry,exit,min time of one idle state sums up to > 500us in some platform, the 100us callback which should be common as > caused by cache miss would also generate 20% imprecision. Don't you A cache miss is causing a 100us callback? What are you talking about? Thanks, tglx
Re: [PATCH v4 1/3] pinctrl/broxton: enable platform device in the absent of ACPI enumeration
On Tue, Jun 21, 2016 at 7:10 AM, Tan Jui Nee wrote: > This is to cater the need for non-ACPI system whereby > a platform device has to be created in order to bind > with the Apollo Lake Pinctrl GPIO platform driver. > > Signed-off-by: Tan Jui Nee > Acked-by: Mika Westerberg This patch is already applied in my tree. Yours, Linus Walleij
Re: [PATCHv3 1/2] usb: USB Type-C connector class
On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote: > On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote: > No it's not. DRP means a port that can operate as _either_ Source > (host) or Sink (device), but not at the same time.. Yes, but it is unclear what you will be after a connection and that's the point. > > And you can be able to become a host and be able to become a device. > > But not at the same time. These ports are switchable. > > > > The current API cannot express the difference. > > I think you have misunderstood something. The only case where the port > can be dual-role is if it's set to be DRP. Otherwise it's Source only > OR Sink only. > > The "Role Supported" bits only tell us how we can program for example > the ROLE_CONTROL registers. I guess the "Roles Supported" bits in > DEVICE_CAPABILITIES are not explained properly, so let's go over them > here: > > 000b = Source _or_ Sink only > 001b = Source only > 010b = Sink only > 011b = Sink only with support for autonomously detected accessory modes > 100b = DRP only, and this I believe mean we can not program the port > to be Sink only or Source only I think so, too. > 101b = Source only OR Sink only OR DRP, plus ability to detect > accessories and I guess also cables autonomously > 110b = Source only OR Sink only OR DRP > > So where the spec lists "Source, Sink", it actually should have said > "Source only OR Sink only". > > But you still have only the following options for a port: > 1) Source only (host) > 2) Sink only (device) > 3) DRP (device, host) Yes, so you can map "000b = Source _or_ Sink only" to host or device depending on the current setting. But then you lose the information that it can be changed. It either will look like "001b" or "010b". So we throw away information. And you map "100b = DRP only" and "101b" and "110b" to host, device which again drops information. Regards Oliver
Re: [PATCH 2/3] staging: lowmemorykiller: count anon pages only when we have swap devices
On (06/22/16 11:27), Ganesh Mahendran wrote:
[..]
> > > Signed-off-by: Ganesh Mahendran
> > > ---
> > > drivers/staging/android/lowmemorykiller.c | 12
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/staging/android/lowmemorykiller.c
> > > b/drivers/staging/android/lowmemorykiller.c
> > > index 6da9260..1d8de47 100644
> > > --- a/drivers/staging/android/lowmemorykiller.c
> > > +++ b/drivers/staging/android/lowmemorykiller.c
> > > @@ -73,10 +73,14 @@ static unsigned long lowmem_deathpending_timeout;
> > > static unsigned long lowmem_count(struct shrinker *s,
> > > struct shrink_control *sc)
> > > {
> > > - return global_page_state(NR_ACTIVE_ANON) +
> > > - global_page_state(NR_ACTIVE_FILE) +
> > > - global_page_state(NR_INACTIVE_ANON) +
> > > - global_page_state(NR_INACTIVE_FILE);
> > > + unsigned long freeable = global_page_state(NR_ACTIVE_FILE) +
> > > + global_page_state(NR_INACTIVE_FILE);
> > > +
> > > + if (get_nr_swap_pages() > 0)
> > > + freeable += global_page_state(NR_ACTIVE_ANON) +
> > > + global_page_state(NR_INACTIVE_ANON);
> > > +
> > > + return freeable;
> > > }
> > >
> > > static unsigned long lowmem_scan(struct shrinker *s, struct
> > > shrink_control *sc)
> >
> > Shouldn't this be advertising the amount of memory that is freeable by
> > killing the process with the highest priority oom_score_adj? It's not
> > legitimate to say it can free all anon and file memory if nothing is oom
> > killable, so this function is wrong both originally and with your patched
> > version.
>
> Yes, so should we just simply return 1 to make do_shrink_slab() go ahead?
> Then lowmem_scan() will do the real job to scan all the process.
hm, looking at ->scan (lowmem_scan) shouldn't it return SHRINK_STOP
when it has nothing to free instead of 0?
-ss
Re: [PATCH v1 2/3] drm: Add API for capturing frame CRCs
On Thu, Jun 23, 2016 at 10:24:46AM +0200, Tomeu Vizoso wrote: > On 23 June 2016 at 10:21, Jani Nikula wrote: > > On Wed, 22 Jun 2016, Daniel Vetter wrote: > >> On Wed, Jun 22, 2016 at 4:31 PM, Thierry Reding > >> wrote: > >>> Perhaps another way to avoid that would be to put the two files into a > >>> separate directory, as in: > >>> > >>> /sys/kernel/debug/dri//crtc-/crc/ > >>> +-- control > >>> +-- data > >>> > >>> That's slightly on the deeply nested side, but on the other hand it > >>> nicely uses the filesystem for namespacing, which is what filesystems > >>> are really good at. > >> > >> crtc-/crc/(control|data) sounds great. > > > > Side note, we should eventually do the same for sink CRCs, but I guess > > under the connectors. i915 currently has a special cased version for eDP > > (named "i915_sink_crc_eDP1"...), reading the data from DPCD. > > Was hoping we could just add one more source to this interface to expose > those. I don't think that would be easy to achieve. You'd have to determine that a sink source is connected to the CRTC and then ajdust the list of possible sources dynamically. For connectors we already have separate directories in debugfs and a sink can easily be found from the connector it is attached to. It's also possible, though I don't know of any that do so currently, that eventually sinks will support several types (i.e. "sources") of CRC, which will further complicate to represent this in the CRTC's list of CRC sources. And it may also be useful to have both CRCs at the same time. The eDP specification for example defines a very specific polynomial that is used to compute the CRC, whereas not all display hardware uses a CRC algorithm that's documented. Finally, the data that will be checksummed by the CRTC isn't necessarily the same as that arriving at the sink. Thierry signature.asc Description: PGP signature
Re: [PATCH v3 2/3] acpi/pmic: Add opregion driver for Intel BXT WhiskeyCove PMIC
On Thu, Jun 23, 2016 at 01:03:30AM -0700, Bin Gao wrote:
> This patch adds operation region driver for Intel BXT WhiskeyCove
> PMIC. The register mapping is done as per the BXT WC data sheet.
>
> Signed-off-by: Ajay Thomas
> Signed-off-by: Felipe Balbi
> Signed-off-by: Chandra Sekhar Anagani
> Signed-off-by: Bin Gao
> ---
> Changes in v3:
> - Added regs_read() and regs_write() methods to the
>intel_pmic_opregion_data{} structure.
> Changs in v2:
> - Replaced module_init() with device_initcall().
> drivers/acpi/Kconfig | 6 +
> drivers/acpi/Makefile| 1 +
> drivers/acpi/pmic/intel_pmic.h | 2 +
> drivers/acpi/pmic/intel_pmic_bxtwc.c | 449
> +++
> 4 files changed, 458 insertions(+)
> create mode 100644 drivers/acpi/pmic/intel_pmic_bxtwc.c
>
> diff --git a/drivers/acpi/pmic/intel_pmic_bxtwc.c
> b/drivers/acpi/pmic/intel_pmic_bxtwc.c
> new file mode 100644
> index 000..51d5bcc
> --- /dev/null
> +++ b/drivers/acpi/pmic/intel_pmic_bxtwc.c
> +static int
> +intel_bxtwc_pmic_regs_read(struct regmap *regmap, u16 address,
> + unsigned int *value)
> +{
> + unsigned int data;
> +
> + if (regmap_read(regmap, address, &data))
> + return -EIO;
> +
> + *value = data;
> + return 0;
> +}
It looks like you can:
static int
intel_bxtwc_pmic_regs_read(struct regmap *regmap, u16 address,
unsigned int *value)
{
return regmap_read(regmap, address, value);
}
But then why adding a new function for no actual use? Or you really need
to return -EIO for all possible regmap_read's error return values? I
don't see such a need.
BTW, the callback functions defined in intel_pmic_opregion_data is there
due to different PMICs have different ways to do the same thing like
turn on/off a power rail, get raw temperature reading, etc. It's not
supposed to host helper functions like the two here.
> +
> +static int
> +intel_bxtwc_pmic_regs_write(struct regmap *regmap, u16 address,
> + unsigned int value)
> +{
> + if (regmap_write(regmap, address, value))
> + return -EIO;
> +
> + return 0;
> +}
Ditto.
> +static struct intel_pmic_opregion_data intel_bxtwc_pmic_opregion_data = {
> + .get_power = intel_bxtwc_pmic_get_power,
> + .update_power = intel_bxtwc_pmic_update_power,
> + .get_raw_temp = intel_bxtwc_pmic_get_raw_temp,
> + .update_aux = intel_bxtwc_pmic_update_aux,
> + .regs_read = intel_bxtwc_pmic_regs_read,
> + .regs_write = intel_bxtwc_pmic_regs_write,
As said above, please drop the two callbacks.
> + .get_policy = intel_bxtwc_pmic_get_policy,
> + .update_policy = intel_bxtwc_pmic_update_policy,
> + .power_table = power_table,
> + .power_table_count = ARRAY_SIZE(power_table),
> + .thermal_table = thermal_table,
> + .thermal_table_count = ARRAY_SIZE(thermal_table),
> +};
Re: [PATCH V7] irq: Track the interrupt timings
On Fri, 17 Jun 2016, Daniel Lezcano wrote: > The interrupt framework gives a lot of information about each interrupt. > > It does not keep track of when those interrupts occur though. > > This patch provides a mean to record the elapsed time between successive > interrupt occurrences in a per-IRQ per-CPU circular buffer to help with the > prediction of the next occurrence using a statistical model. > > A new function is added to browse the different interrupts and retrieve the > timing information stored in it. > > A static key is introduced so when the irq prediction is switched off at > runtime, we can reduce the overhead near to zero. The irq timings is > supposed to be potentially used by different sub-systems and for this reason > the static key is a ref counter, so when the last use releases the irq > timings that will result on the effective deactivation of the irq measurement. Before merging this I really have to ask a few more questions. I'm a bit worried about the usage site of this. It's going to iterate over all interrupts in the system to do a next interrupt prediction. On larger machines that's going to be quite some work and you touch a gazillion of cache lines and many of them just to figure out that nothing happened. Is it really required to do this per interrupt rather than providing per cpu statistics of interrupts which arrived in the last X seconds or whatever timeframe is relevant for this. Thanks, tglx
Re: [PATCH v02 4/5] perf/x86/intel: MSR_LAST_BRANCH_FROM_x quirk for ctx switch
On Tue, Jun 21, 2016 at 11:31:13AM -0700, David Carrillo-Cisneros wrote:
> @@ -297,7 +312,8 @@ static void __intel_pmu_lbr_restore(struct
> x86_perf_task_context *task_ctx)
> tos = task_ctx->tos;
> for (i = 0; i < tos; i++) {
> lbr_idx = (tos - i) & mask;
> - wrmsrl(x86_pmu.lbr_from + lbr_idx, task_ctx->lbr_from[i]);
> + wrmsrl(x86_pmu.lbr_from + lbr_idx,
> + lbr_from_signext_quirk_wr(task_ctx->lbr_from[i]));
> wrmsrl(x86_pmu.lbr_to + lbr_idx, task_ctx->lbr_to[i]);
> if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_INFO)
> wrmsrl(MSR_LBR_INFO_0 + lbr_idx, task_ctx->lbr_info[i]);
> @@ -321,7 +337,8 @@ static void __intel_pmu_lbr_save(struct
> x86_perf_task_context *task_ctx)
> tos = intel_pmu_lbr_tos();
> for (i = 0; i < tos; i++) {
> lbr_idx = (tos - i) & mask;
> - rdmsrl(x86_pmu.lbr_from + lbr_idx, task_ctx->lbr_from[i]);
> + rdmsrl(x86_pmu.lbr_from + lbr_idx, val);
> + task_ctx->lbr_from[i] = lbr_from_signext_quirk_rd(val);
> rdmsrl(x86_pmu.lbr_to + lbr_idx, task_ctx->lbr_to[i]);
> if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_INFO)
> rdmsrl(MSR_LBR_INFO_0 + lbr_idx, task_ctx->lbr_info[i]);
> @@ -499,6 +516,8 @@ static void intel_pmu_lbr_read_64(struct cpu_hw_events
> *cpuc)
> int lbr_flags = lbr_desc[lbr_format];
>
> rdmsrl(x86_pmu.lbr_from + lbr_idx, from);
> + from = lbr_from_signext_quirk_rd(from);
> +
> rdmsrl(x86_pmu.lbr_to + lbr_idx, to);
>
> if (lbr_format == LBR_FORMAT_INFO && need_info) {
I did this on top...
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -288,12 +288,42 @@ inline u64 lbr_from_signext_quirk_wr(u64
u64 lbr_from_signext_quirk_rd(u64 val)
{
- if (static_branch_unlikely(&lbr_from_quirk_key))
+ if (static_branch_unlikely(&lbr_from_quirk_key)) {
/*
* Quirk is on when TSX is not enabled. Therefore TSX
* flags must be read as OFF.
*/
val &= ~(LBR_FROM_FLAG_IN_TX | LBR_FROM_FLAG_ABORT);
+ }
+ return val;
+}
+
+static inline void wrlbr_from(unsigned int idx, u64 val)
+{
+ val = lbr_from_signext_quirk_wr(val);
+ wrmsrl(x86_pmu.lbr_from + idx, val);
+}
+
+static inline void wrlbr_to(unsigned int idx, u64 val)
+{
+ wrmsrl(x86_pmu.lbr_to + idx, val);
+}
+
+static inline u64 rdlbr_from(unsigned int idx)
+{
+ u64 val;
+
+ rdmsrl(x86_pmu.lbr_from + idx, val);
+
+ return lbr_from_signext_quirk_rd(val);
+}
+
+static inline u64 rdlbr_to(unsigned int idx)
+{
+ u64 val;
+
+ rdmsrl(x86_pmu.lbr_from + idx, val);
+
return val;
}
@@ -313,9 +343,9 @@ static void __intel_pmu_lbr_restore(stru
tos = task_ctx->tos;
for (i = 0; i < tos; i++) {
lbr_idx = (tos - i) & mask;
- wrmsrl(x86_pmu.lbr_from + lbr_idx,
- lbr_from_signext_quirk_wr(task_ctx->lbr_from[i]));
- wrmsrl(x86_pmu.lbr_to + lbr_idx, task_ctx->lbr_to[i]);
+ wrlbr_from(lbr_idx, task_ctx->lbr_from[i]);
+ wrlbr_to (lbr_idx, task_ctx->lbr_to[i]);
+
if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_INFO)
wrmsrl(MSR_LBR_INFO_0 + lbr_idx, task_ctx->lbr_info[i]);
}
@@ -325,9 +355,9 @@ static void __intel_pmu_lbr_restore(stru
static void __intel_pmu_lbr_save(struct x86_perf_task_context *task_ctx)
{
- int i;
unsigned lbr_idx, mask;
- u64 tos, val;
+ u64 tos;
+ int i;
if (task_ctx->lbr_callstack_users == 0) {
task_ctx->lbr_stack_state = LBR_NONE;
@@ -338,9 +368,8 @@ static void __intel_pmu_lbr_save(struct
tos = intel_pmu_lbr_tos();
for (i = 0; i < tos; i++) {
lbr_idx = (tos - i) & mask;
- rdmsrl(x86_pmu.lbr_from + lbr_idx, val);
- task_ctx->lbr_from[i] = lbr_from_signext_quirk_rd(val);
- rdmsrl(x86_pmu.lbr_to + lbr_idx, task_ctx->lbr_to[i]);
+ task_ctx->lbr_from[i] = rdlbr_from(lbr_idx);
+ task_ctx->lbr_to[i] = rdlbr_to(lbr_idx);
if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_INFO)
rdmsrl(MSR_LBR_INFO_0 + lbr_idx, task_ctx->lbr_info[i]);
}
@@ -516,10 +545,8 @@ static void intel_pmu_lbr_read_64(struct
u16 cycles = 0;
int lbr_flags = lbr_desc[lbr_format];
- rdmsrl(x86_pmu.lbr_from + lbr_idx, from);
- from = lbr_from_signext_quirk_rd(from);
-
- rdmsrl(x86_pmu.lbr_to + lbr_idx, to);
+ from = rdlbr_from(lbr_idx);
+ to = rdlbr_to(lbr_idx);
if (lbr_format == LBR_FORMAT_INFO && need_
Re: [PATCH v4 2/3] x86/platform/p2sb: New Primary to Sideband bridge support driver for Intel SOC's
On Tue, Jun 21, 2016 at 7:10 AM, Tan Jui Nee wrote: > From: Andy Shevchenko > > There is already one and at least one more user coming which > require an access to Primary to Sideband bridge (P2SB) in order > to get IO or MMIO bar hidden by BIOS. > Create a driver to access P2SB for x86 devices. > > Signed-off-by: Yong, Jonathan > Signed-off-by: Andy Shevchenko > --- > Changes in V4: > - Move Kconfig option CONFIG_X86_INTEL_NON_ACPI from > [PATCH 2/3] x86/platform/p2sb: New Primary to Sideband bridge > support driver for Intel SOC's > to > [PATCH 3/3] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO > pinctrl in non-ACPI system > since the config is used in latter patch. Waiting for a respin in accordance with Mika's comments. You don't need to resend patch 1/3 it is already applied. Yours, Linus Walleij
Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length
On 23 June 2016 at 16:35, Thomas Gleixner wrote: > On Thu, 23 Jun 2016, Zhaoyang Huang wrote: >> On 23 June 2016 at 16:18, Thomas Gleixner wrote: >> > On Thu, 23 Jun 2016, Zhaoyang Huang wrote: >> >> On 23 June 2016 at 15:01, Thomas Gleixner wrote: >> >> Thomas, I agree with you, I have discussed the modification with the >> >> call back owner. However, I wonder if we can make the idle's framework >> >> to be more precised without the assumption of short CPU_PM_ENTER >> >> callbacks. Thank you! >> > >> > What's the point? To help people who put insanities into the idle code >> > path? >> > >> > Thanks, >> > >> > tglx >> > >> Hi, Thomas. If the entry,exit,min time of one idle state sums up to >> 500us in some platform, the 100us callback which should be common as >> caused by cache miss would also generate 20% imprecision. Don't you > > A cache miss is causing a 100us callback? What are you talking about? > > Thanks, > > tglx By a serials of memory access which maybe missed on cache all. Anyway, we can require the callback not to introduce schedule etc, but can not ask them to ensure their own executing time, which they can not control.
Re: [PATCH v4 3/3] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO pinctrl in non-ACPI system
On Tue, Jun 21, 2016 at 7:10 AM, Tan Jui Nee wrote: > This driver uses the P2SB hide/unhide mechanism cooperatively > to pass the PCI BAR address to the gpio platform driver. > > Signed-off-by: Tan Jui Nee > --- > Changes in V4: > - Move Kconfig option CONFIG_X86_INTEL_NON_ACPI from > [PATCH 2/3] x86/platform/p2sb: New Primary to Sideband bridge > support driver for Intel SOC's > to > [PATCH 3/3] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO > pinctrl in non-ACPI system > since the config is used in latter patch. > - Select CONFIG_P2SB when CONFIG_LPC_ICH is enabled. > - Remove #ifdef CONFIG_X86_INTEL_NON_ACPI and use > #if defined(CONFIG_X86_INTEL_NON_ACPI) when lpc_ich_misc is called > as suggested by Lee Jones. > - Use single dimensional array instead of 2D array for apl_gpio_io_res > structure and use DEFINE_RES_IRQ for its IRQ resource. I guess this patch will also change, also fix the screamings from the build robot please. Yours, Linus Walleij
Re: [PATCH] pinctrl: sh-pfc: r8a7795: use PINMUX_SINGLE() for I2C
On Tue, Jun 21, 2016 at 9:21 AM, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > Now we have PINMUX_SINGLE(). Let's use it instead of PINMUX_IPSR_NOGP() > > Signed-off-by: Kuninori Morimoto > Reviewed-by: Geert Uytterhoeven Acked-by: Linus Walleij Geert, are you queuing this? Yours, Linus Walleij
Re: [PATCH] fbdev: atyfb: fix array overflow
Hi Arnd,
On Wed, Jun 22, 2016 at 2:37 PM, Arnd Bergmann wrote:
> When building with CONFIG_UBSAN_SANITIZE_ALL on ARM, I get this
> gcc warning for atyfb:
>
> drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_bl_update_status':
> drivers/video/fbdev/aty/atyfb_base.c:167:33: warning: array subscript is
> above array bounds [-Warray-bounds]
> drivers/video/fbdev/aty/atyfb_base.c:152:26: warning: array subscript is
> above array bounds [-Warray-bounds]
>
> Apparently the warning is correct and there is indeed an overflow,
> which was never caught. I could only reproduce this on ARM and
> have opened a bug against the compiler for the lack of warning.
>
> This patch makes the array larger, so we cover all possible
> registers in the LCD controller without an overflow.
>
> Signed-off-by: Arnd Bergmann
> Link: https://bugs.linaro.org/show_bug.cgi?id=2349
> ---
> drivers/video/fbdev/aty/atyfb_base.c | 2 +-
> include/video/mach64.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/aty/atyfb_base.c
> b/drivers/video/fbdev/aty/atyfb_base.c
> index 001d3d871800..36ffba152eab 100644
> --- a/drivers/video/fbdev/aty/atyfb_base.c
> +++ b/drivers/video/fbdev/aty/atyfb_base.c
> @@ -134,7 +134,7 @@
>
> #if defined(CONFIG_PM) || defined(CONFIG_PMAC_BACKLIGHT) || \
> defined (CONFIG_FB_ATY_GENERIC_LCD) || defined(CONFIG_FB_ATY_BACKLIGHT)
> -static const u32 lt_lcd_regs[] = {
> +static const u32 lt_lcd_regs[LCD_REG_NUM] = {
> CNFG_PANEL_LG,
> LCD_GEN_CNTL_LG,
> DSTN_CONTROL_LG,
> diff --git a/include/video/mach64.h b/include/video/mach64.h
> index 89e91c0cb737..9f74e9e0aeb8 100644
> --- a/include/video/mach64.h
> +++ b/include/video/mach64.h
> @@ -1299,6 +1299,7 @@
> #define APC_LUT_KL 0x38
> #define APC_LUT_MN 0x39
> #define APC_LUT_OP 0x3A
> +#define LCD_REG_NUM0x3B /* total number */
>
> /* Values in LCD_GEN_CTRL */
> #define CRT_ON 0x0001ul
This doesn't look like the right fix to me.
Before, aty_st_lcd(LCD_MISC_CNTL, reg, par) in aty_bl_update_status()
wrote into an arbitrary register.
With your fix, it will write to register 0, which is IMHO also not OK.
I think aty_st_lcd() and aty_ld_lcd() should check whether the index is
out of range, perhaps even with a WARN_ON()?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/3] iio: potentiometer: mcp4531: Add device tree binding
Hello Peter,
On 06/22/2016 09:06 AM, Peter Rosin wrote:
> On 2016-06-22 08:22, Florian Vaussard wrote:
>> Hello Peter,
>>
>> Le 21. 06. 16 à 09:51, Peter Rosin a écrit :
>>> That is, if you need this patch at all, see my reply to 2/3...
>>>
>>
>> This seems necessary in order to have the vendor ID in the compatible string.
>
> Hmm, I don't think so. The way I read the response from Rob was that
> *my* device tree snippet should not assume that the i2c subsystem
> ignores the vendor. So, I think that even w/o this patch a DT entry
> like
>
> mcp4651-104@28 {
> compatible = "microchip,mcp4651-104";
> reg = <0x28>;
> };
>
> will work, precisely since i2c ignores the microchip, part (and thus
> allows you to omit/misspell it). I.e. I think that Rob is concerned
> with how the DT is documented/defined, and not so much about how it
> is then implemented in Linux.
>
The way that I read Rob's reply is reverse: you should not rely on the matching
done by i2c subsystem and provide a proper of_device_id table instead.
I think that ignoring the vendor when matching the compatible, like what is
currently done by the i2c subsystem, is bad. What happens if you have two chips
from two companies with the same name (yes it happens)? You may need different
data to address the small specificities of each chip, or even worse a different
driver at all. This implies that we should explicitly match the vendor as well,
otherwise we would be unable to cope with such cases.
Moreover, if we look at the current i2c drivers, a whole bunch of them already
have a of_device_id table:
(on v4.6)
$ git grep -l i2c_device_id | wc -l
636
$ git grep -l i2c_device_id | xargs grep -l 'of_device_id' | wc -l
197
Currently 30% of all i2c drivers explicitly declare DT compatible strings. And I
am sure that this number will keep increasing as drivers are converted to DT.
Regards,
Florian
Re: [PATCH] irqchip: fix the config HISILICON_IRQ_MBIGEN dependency error.
Hi Marc,
On 2016/6/21 20:49, Marc Zyngier wrote:
> On 21/06/16 13:01, Jiancheng Xue wrote:
>>
>>
>> On 2016/6/21 19:30, Jiancheng Xue wrote:
>>> Hi Marc，
>>>
>>> On 2016/6/21 18:36, Marc Zyngier wrote:
On 21/06/16 10:26, Jiancheng Xue wrote:
> This patch fixes the compiling error caused when
> config HISILICON_IRQ_MBIGEN is selected but
> PCI_MSI is not seleted.
>
> Signed-off-by: Jiancheng Xue
> ---
> drivers/irqchip/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index fa33c50..23dcf3e 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -110,7 +110,7 @@ config DW_APB_ICTL
> config HISILICON_IRQ_MBIGEN
> bool
> select ARM_GIC_V3
> - select ARM_GIC_V3_ITS
> + select ARM_GIC_V3_ITS if PCI_MSI
> select GENERIC_MSI_IRQ_DOMAIN
How can this be correct? The MBIGEN uses platform MSI (not PCI) and
relies on the ITS (it doesn't work without it). It seems that you're
papering over another issue.
>>> Sorry. I am not familiar with this part. But I encountered errors when
>>> I compiled. I think there may be some problems about dependency.
>>>
>>> In this Kconfig file
>>>
>>> config ARM_GIC_V3_ITS
>>> bool
>>> select PCI_MSI_IRQ_DOMAIN
>>>
>>> config HISILICON_IRQ_MBIGEN
>>> bool
>>> select ARM_GIC_V3
>>> select ARM_GIC_V3_ITS
>>> select GENERIC_MSI_IRQ_DOMAIN
>>>
>>> In the file drivers/pci/Kconfig
>>>
>>> config PCI_MSI_IRQ_DOMAIN
>>> bool
>>> depends on PCI_MSI
>>> select GENERIC_MSI_IRQ_DOMAIN
>>>
>>> We can see if the HISILICON_IRQ_MBIGEN is selected, the ARM_GIC_V3_ITS and
>>> PCI_MSI_IRQ_DOMAIN will be selected. But PCI_MSI_IRQ_DOMAIN depends on
>>> PCI_MSI. If PCI_MSI is not selected, it will cause a compiling error like
>>> this
>>> "drivers/irqchip/irq-gic-v3-its-pci-msi.c:52:12: error: implicit
>>> declaration of function 'pci_msi_vec_count'
>>> [-Werror=implicit-function-declaration]
>>> msi = max(pci_msi_vec_count(pdev), 0);"
>>>
>>> I found many other options which need ARM_GIC_V3_ITS or PCI_MSI_IRQ_DOMAIN
>>> were configured like below:
>>> select ARM_GIC_V3_ITS if PCI_MSI
>>> or
>>> select GENERIC_MSI_IRQ_DOMAIN if PCI_MSI
>>>
>>
>> This patch is really not correct. It will cause new problems.
>>
>> In drivers/irqchip/Makefile
>>
>> obj-$(CONFIG_ARM_GIC_V3_ITS)+= irq-gic-v3-its.o
>> irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o
>>
>> if CONFIG_ARM_GIC_V3_ITS is selected, irq-gic-v3-its-pci-msi.c will be
>> compiled. But it depends on config PCI_MSI.
>>
>> if irq-gic-v3-its-pci-msi.c is not relied on by irq-gic-v3-its.c, maybe it
>> should be controlled by another config
>> item instead of CONFIG_ARM_GIC_V3_ITS. Otherwise, CONFIG_ARM_GIC_V3_ITS
>> should depend on PCI_MSI.
>
> Can you check this patch out:
>
> https://patchwork.kernel.org/patch/9179303/
>
> and let people know if that solves your problem or not?
>
I applied this patch from -next tree (commit 3ee803641e76bea) and compiled with
my configure file
in which CONFIG_PCI is not set.
Some warning and error messages are as follows:
warning: (ARM64 && HISILICON_IRQ_MBIGEN) selects ARM_GIC_V3_ITS which has unmet
direct dependencies (PCI && PCI_MSI)
...
CC drivers/irqchip/irq-gic-v3-its.o
drivers/irqchip/irq-gic-v3-its.c:1283:17: error: unknown type name
'msi_alloc_info_t'
int nvec, msi_alloc_info_t *info)
^
drivers/irqchip/irq-gic-v3-its.c:1322:15: error: variable 'its_msi_domain_ops'
has initializer but incomplete type
static struct msi_domain_ops its_msi_domain_ops = {
^
drivers/irqchip/irq-gic-v3-its.c:1323:2: error: unknown field 'msi_prepare'
specified in initializer
.msi_prepare = its_msi_prepare,
^
drivers/irqchip/irq-gic-v3-its.c:1323:17: error: 'its_msi_prepare' undeclared
here (not in a function)
.msi_prepare = its_msi_prepare,
^
drivers/irqchip/irq-gic-v3-its.c:1323:17: warning: excess elements in struct
initializer
drivers/irqchip/irq-gic-v3-its.c:1323:17: note: (near initialization for
'its_msi_domain_ops')
drivers/irqchip/irq-gic-v3-its.c: In function 'its_irq_domain_alloc':
drivers/irqchip/irq-gic-v3-its.c:1348:2: error: unknown type name
'msi_alloc_info_t'
msi_alloc_info_t *info = args;
^
drivers/irqchip/irq-gic-v3-its.c:1349:35: error: request for member
'scratchpad' in something not a structure or union
struct its_device *its_dev = info->scratchpad[0].ptr;
^
drivers/irqchip/irq-gic-v3-its.c: In function 'its_probe':
drivers/irqchip/irq-gic-v3-its.c:1611:25: error: dereferencing pointer to
incomplete type 'struct msi_domain_info'
info = kzalloc(sizeof(*info), GFP_KERNEL);
^
drivers/irqchip/irq-gic-v3-its.c: At top level:
drivers/irqchip/irq-gic-v3-its.c:1157:27: warning:
Re: [PATCH 3.14 21/29] netfilter: x_tables: validate targets of jumps
Greg Kroah-Hartman wrote:
> 3.14-stable review patch. If anyone has any objections, please let me know.
I have -- this doesn't work in 3.14 as t->entries (the ruleset blob)
is still kept percpu.
> +static bool find_jump_target(const struct xt_table_info *t,
> + const struct arpt_entry *target)
> +{
> + struct arpt_entry *iter;
> +
> + xt_entry_foreach(iter, t->entries, t->size) {
.. so this causes in kernel soft lockup when I try to insert a rule.
I will go over the 3.14 stable queue and see if I can amend this to work
with 3.14.
[PATCH v10 2/3] perf config: Reimplement perf_config() introducing new perf_config_init() and perf_config_finish()
Many sub-commands use perf_config() but
everytime perf_config() is called, perf_config() always read config files.
(i.e. user config '~/.perfconfig' and system config '$(sysconfdir)/perfconfig')
But it is better to use the config set that already contains all config
key-value pairs to avoid this repetitive work reading the config files
in perf_config(). (the config set mean a static variable 'config_set')
In other words, if new perf_config_init() is called,
only first time 'config_set' is initialized collecting all configs from the
config files.
And then we could use new perf_config() like old perf_config().
When a sub-command finished, free the config set by perf_config_finish() at
run_builtin().
If we do, 'config_set' can be reused wherever perf_config() is called
and a feature of old perf_config() is the same as new perf_config() work
without the repetitive work that read the config files.
In summary, in order to use features about configuration,
we can call the functions at perf.c and other source files as below.
# initialize a config set
perf_config_init()
# configure actual variables from a config set
perf_config()
# eliminate allocated config set
perf_config_finish()
# destroy existing config set and initialize a new config set.
perf_config_refresh()
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/builtin-config.c | 4 ++
tools/perf/perf.c | 2 +
tools/perf/util/config.c| 92 +++--
tools/perf/util/config.h| 29 ++
4 files changed, 82 insertions(+), 45 deletions(-)
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index fe1b77f..cfd1036 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -80,6 +80,10 @@ int cmd_config(int argc, const char **argv, const char
*prefix __maybe_unused)
else if (use_user_config)
config_exclusive_filename = user_config;
+ /*
+* At only 'config' sub-command, individually use the config set
+* because of reinitializing with options config file location.
+*/
set = perf_config_set__new();
if (!set) {
ret = -1;
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 66772da..280967e 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -355,6 +355,7 @@ static int run_builtin(struct cmd_struct *p, int argc,
const char **argv)
perf_env__set_cmdline(&perf_env, argc, argv);
status = p->fn(argc, argv, prefix);
+ perf_config_finish();
exit_browser(status);
perf_env__exit(&perf_env);
bpf__clear();
@@ -522,6 +523,7 @@ int main(int argc, const char **argv)
srandom(time(NULL));
+ perf_config_init();
perf_config(perf_default_config, NULL);
set_buildid_dir(NULL);
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index d15c592..a16f95d 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -26,6 +26,7 @@ static FILE *config_file;
static const char *config_file_name;
static int config_linenr;
static int config_file_eof;
+static struct perf_config_set *config_set;
const char *config_exclusive_filename;
@@ -478,51 +479,6 @@ static int perf_config_global(void)
return !perf_env_bool("PERF_CONFIG_NOGLOBAL", 0);
}
-int perf_config(config_fn_t fn, void *data)
-{
- int ret = -1;
- const char *home = NULL;
-
- /* Setting $PERF_CONFIG makes perf read _only_ the given config file. */
- if (config_exclusive_filename)
- return perf_config_from_file(fn, config_exclusive_filename,
data);
- if (perf_config_system() && !access(perf_etc_perfconfig(), R_OK)) {
- if (perf_config_from_file(fn, perf_etc_perfconfig(), data) < 0)
- goto out;
- }
-
- home = getenv("HOME");
- if (perf_config_global() && home) {
- char *user_config = strdup(mkpath("%s/.perfconfig", home));
- struct stat st;
-
- if (user_config == NULL) {
- warning("Not enough memory to process %s/.perfconfig, "
- "ignoring it.", home);
- goto out;
- }
-
- if (stat(user_config, &st) < 0)
- goto out_free;
-
- if (st.st_uid && (st.st_uid != geteuid())) {
- warning("File %s not owned by current user or root, "
- "ignoring it.", user_config);
- goto out_free;
- }
-
- if (!st.st_size)
- goto out_free;
-
- ret = perf_config_from_file(fn, user_config, data);
-
-out_free:
- free(user_config);
- }
-out:
- return ret;
-
[PATCH v10 0/3] perf config: Reimplement perf_config()
Hello, :) This patchset is to reimplement perf_config() for efficient config management. Many sub-commands use perf_config() but everytime perf_config() is called, perf_config() always read config files. (i.e. user config '~/.perfconfig' and system config '$(sysconfdir)/perfconfig') But it is better to use the config set that already contains all config key-value pairs to avoid this repetitive work reading the config files in perf_config(). In summary, in order to use features about configuration, we can call the functions at perf.c and other source files as below. # initialize a config set perf_config_init() # configure actual variables from a config set perf_config() # eliminate allocated config set perf_config_finish() # destroy existing config set and initialize a new config set. perf_config_refresh() IMHO, I think this patchset is needed because not only the repetitive work should be avoided but also in near future, it would be smooth to manage perf configs. If you give me any feedback, I'd apprecicated it. :) Thanks, Taeung v10: - rebased onto current acme/perf/core v9: - add config_set__for_each macro (Arnaldo) - the source files that only need config.h don't include cache.h (Arnaldo) - use 'config_set' as a static variable instead of a global variable. (Namhyung) - add perf_config_init(), perf_config_finish() and perf_config_refresh() (Namhyung) - remove [PATCH v8 4/5] perf config: Use zfree() instead of free() at perf_config_set__delete() - rebased onto current acme/perf/core - applied ([BUGFIX][PATCH v8 1/5] 826424) v8: - handle the error about NULL at perf_config_set__delete() - bring declarations about config from util/config.h to util/config.h - reimplement show_config() using perf_config_set__iter() instead of perf_config() - rebased onto perf-core-for-mingo-20160607 - applied ([PATCH v7 1/7] 25d8f48, [PATCH v7 2/7] 8beeb00) v7: - fill a missing crumb that assign NULL to 'set' variable in perf_config_set__new() (Arnaldo) - two patches applied ([PATCH v6 1/9] 78f71c9, [PATCH v6 3/9] 7db91f2) v6: - add printing error message when perf_config_set__iter() is failed - modify commit messages for bugfix 1~3 (PATCH 1/9 ~ 3/9) to help reviewers easily understand why them is needed v5: - solve the leak when perf_config_set__init() failed (Arnaldo) (to clear the problem it is needed to apply the bottom bugfix 1~3 patches) - bugfix 1) fix the problem of abnormal terminaltion at perf_parse_file() called by perf_config() - bugfix 2) if failed at collect_config(), finally free a config set after it is done instead of freeing the config set in the function - bugfix 3) handle NULL pointer exception of 'set' at collect_config() v4: - Keep perf_config_set__delete() as it is (Arnaldo) - Remove perf_config_set__check() (Arnaldo) - Keep the existing code about the config set at cmd_config() (Arnaldo) v3: - add freeing config set after sub-command work at run_builtin() (Namhyung) - remove needless code about the config set at cmd_config() - add a patch about a global variable 'config_set' v2: - split a patch into several patches - reimplement show_config() using new perf_config() - modify perf_config_set__delete using global variable 'config_set' - reset config set when only 'config' sub-commaned work because of options for config file location Taeung Song (3): perf config: Bring declarations about config from util/cache.h to util/config.h perf config: Reimplement perf_config() introducing new perf_config_init() and perf_config_finish() perf config: Reimplement show_config() using config_set__for_each tools/perf/builtin-config.c| 21 - tools/perf/builtin-help.c | 2 +- tools/perf/builtin-kmem.c | 2 +- tools/perf/builtin-record.c| 1 + tools/perf/builtin-report.c| 2 +- tools/perf/builtin-top.c | 2 +- tools/perf/perf.c | 4 +- tools/perf/ui/browser.c| 2 +- tools/perf/ui/browsers/annotate.c | 1 + tools/perf/util/alias.c| 1 + tools/perf/util/cache.h| 11 - tools/perf/util/color.c| 1 + tools/perf/util/config.c | 92 +++--- tools/perf/util/config.h | 40 + tools/perf/util/help-unknown-cmd.c | 1 + tools/perf/util/intel-pt.c | 1 + tools/perf/util/llvm-utils.c | 1 + 17 files changed, 111 insertions(+), 74 deletions(-) -- 2.5.0
[PATCH] tools/vm/slabinfo: fix spelling mistake: "Ocurrences" -> "Occurrences"
From: Colin Ian King
trivial fix to spelling mistake
Signed-off-by: Colin Ian King
---
tools/vm/slabinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/vm/slabinfo.c b/tools/vm/slabinfo.c
index 1889163..7cf6e17 100644
--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -492,7 +492,7 @@ static void slab_stats(struct slabinfo *s)
s->deactivate_to_head + s->deactivate_to_tail +
s->deactivate_bypass;
if (total) {
- printf("\nSlab Deactivation Ocurrences %%\n");
+ printf("\nSlab Deactivation Occurrences %%\n");
printf("-\n");
printf("Slab full %7lu %3lu%%\n",
s->deactivate_full, (s->deactivate_full * 100) / total);
--
2.8.1
[PATCH v10 3/3] perf config: Reimplement show_config() using config_set__for_each
Lately config_set__for_each is added.
In order to let show_config() be short and clear,
remake this function using config_set__for_each macro
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Alexander Shishkin
Cc: Wang Nan
Signed-off-by: Taeung Song
---
tools/perf/builtin-config.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index cfd1036..c144643 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -37,23 +37,16 @@ static int show_config(struct perf_config_set *set)
{
struct perf_config_section *section;
struct perf_config_item *item;
- struct list_head *sections;
if (set == NULL)
return -1;
- sections = &set->sections;
- if (list_empty(sections))
- return -1;
-
- list_for_each_entry(section, sections, node) {
- list_for_each_entry(item, §ion->items, node) {
- char *value = item->value;
+ config_set__for_each(set, section, item) {
+ char *value = item->value;
- if (value)
- printf("%s.%s=%s\n", section->name,
- item->name, value);
- }
+ if (value)
+ printf("%s.%s=%s\n", section->name,
+ item->name, value);
}
return 0;
--
2.5.0
Re: [PATCH v12 2/4] gadget: Support for the usb charger framework
Hi,
On 21 June 2016 at 18:27, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> For supporting the usb charger, it adds the usb_charger_init() and
>> usb_charger_exit() functions for usb charger initialization and exit.
>>
>> It will report to the usb charger when the gadget state is changed,
>> then the usb charger can do the power things.
>>
>> Signed-off-by: Baolin Wang
>> Reviewed-by: Li Jun
>> Tested-by: Li Jun
>
> Before anything, I must say that I really liked this patch. It's
> minimaly invasive to udc core and does all the necessary changes. If it
> wasn't for the extra charger class, this would've been perfect.
>
> Can't you just tie a charger to a UDC and avoid the charger class
> completely?
>
>> static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned
>> mA)
>> {
>> + if (gadget->charger)
>
> I guess you could do this check inside
> usb_gadget_set_cur_limit_by_type() itself.
We will access the 'gadget->charger->type' member when issuing
usb_gadget_set_cur_limit_by_type(), so I think I should leave the
check here in next new version.
--
Baolin.wang
Best Regards
