dfl-afu-dma-region.c:undefined reference to `dma_direct_map_page'
Hi Christoph, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b5aef86e089a2d85a6d627372287785d08938cbe commit: 356da6d0cde3323236977fce54c1f9612a742036 dma-mapping: bypass indirect calls for dma-direct date: 3 weeks ago config: um-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 356da6d0cde3323236977fce54c1f9612a742036 # save the attached .config to linux build tree make ARCH=um All errors (new ones prefixed by >>): arch/um/drivers/vde.o: In function `vde_open_real': (.text+0x951): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking (.text+0x79c): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/vector_user.o: In function `user_init_socket_fds': vector_user.c:(.text+0x334): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/pcap.o: In function `pcap_nametoaddr': (.text+0xdee5): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/pcap.o: In function `pcap_nametonetaddr': (.text+0xdf85): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/pcap.o: In function `pcap_nametoproto': (.text+0xe1a5): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/pcap.o: In function `pcap_nametoport': (.text+0xdfd7): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking drivers/dma-buf/udmabuf.o: In function `map_udmabuf': udmabuf.c:(.text+0x316): undefined reference to `dma_direct_map_sg' drivers/fpga/dfl-afu-dma-region.o: In function `afu_dma_map_region': >> dfl-afu-dma-region.c:(.text+0xe56): undefined reference to >> `dma_direct_map_page' collect2: error: ld returned 1 exit status --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH 2/2] tpm/eventlog/tpm1: Fix off-by-1 when reading binary_bios_measurements
It is unable to read the entry when it is the only one in
binary_bios_measurements:
00 00 00 00 08 00 00 00 c4 2f ed ad 26 82 00 cb
0010 1d 15 f9 78 41 c3 44 e7 9d ae 33 20 00 00 00 00
0020
This is obviously a firmware problem on my linux machine:
Manufacturer: Inspur
Product Name: SA5212M4
Version: 01
However, binary_bios_measurements should return it any way,
rather than nothing, after all its content is completely
valid.
Fix: 55a82ab("tpm: add bios measurement log")
Signed-off-by: Jia Zhang
---
drivers/char/tpm/eventlog/tpm1.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/eventlog/tpm1.c b/drivers/char/tpm/eventlog/tpm1.c
index 4cf8303..bfdff92 100644
--- a/drivers/char/tpm/eventlog/tpm1.c
+++ b/drivers/char/tpm/eventlog/tpm1.c
@@ -88,7 +88,7 @@ static void *tpm1_bios_measurements_start(struct seq_file *m,
loff_t *pos)
event = addr;
/* check if current entry is valid */
- if (addr + sizeof(struct tcpa_event) >= limit)
+ if (addr + sizeof(struct tcpa_event) > limit)
return NULL;
converted_event_size =
@@ -98,7 +98,7 @@ static void *tpm1_bios_measurements_start(struct seq_file *m,
loff_t *pos)
if (((converted_event_type == 0) && (converted_event_size == 0))
|| ((addr + sizeof(struct tcpa_event) +
converted_event_size)
- >= limit))
+ > limit))
return NULL;
if (i++ == *pos)
@@ -125,7 +125,7 @@ static void *tpm1_bios_measurements_next(struct seq_file
*m, void *v,
v += sizeof(struct tcpa_event) + converted_event_size;
/* now check if current entry is valid */
- if ((v + sizeof(struct tcpa_event)) >= limit)
+ if ((v + sizeof(struct tcpa_event)) > limit)
return NULL;
event = v;
@@ -134,7 +134,7 @@ static void *tpm1_bios_measurements_next(struct seq_file
*m, void *v,
converted_event_type = do_endian_conversion(event->event_type);
if (((converted_event_type == 0) && (converted_event_size == 0)) ||
- ((v + sizeof(struct tcpa_event) + converted_event_size) >= limit))
+ ((v + sizeof(struct tcpa_event) + converted_event_size) > limit))
return NULL;
(*pos)++;
--
1.8.3.1
[PATCH 1/2] tpm/eventlog/tpm1: Simplify walking over *pos measurements
The sanity check would be easier, especially for the first read
of binary_bios_measurements from the beginning.
Signed-off-by: Jia Zhang
---
drivers/char/tpm/eventlog/tpm1.c | 37 ++---
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/char/tpm/eventlog/tpm1.c b/drivers/char/tpm/eventlog/tpm1.c
index 58c8478..4cf8303 100644
--- a/drivers/char/tpm/eventlog/tpm1.c
+++ b/drivers/char/tpm/eventlog/tpm1.c
@@ -74,7 +74,7 @@
/* returns pointer to start of pos. entry of tcg log */
static void *tpm1_bios_measurements_start(struct seq_file *m, loff_t *pos)
{
- loff_t i;
+ loff_t i = 0;
struct tpm_chip *chip = m->private;
struct tpm_bios_log *log = >log;
void *addr = log->bios_event_log;
@@ -83,38 +83,29 @@ static void *tpm1_bios_measurements_start(struct seq_file
*m, loff_t *pos)
u32 converted_event_size;
u32 converted_event_type;
-
/* read over *pos measurements */
- for (i = 0; i < *pos; i++) {
+ do {
event = addr;
+ /* check if current entry is valid */
+ if (addr + sizeof(struct tcpa_event) >= limit)
+ return NULL;
+
converted_event_size =
do_endian_conversion(event->event_size);
converted_event_type =
do_endian_conversion(event->event_type);
- if ((addr + sizeof(struct tcpa_event)) < limit) {
- if ((converted_event_type == 0) &&
- (converted_event_size == 0))
- return NULL;
- addr += (sizeof(struct tcpa_event) +
-converted_event_size);
- }
- }
-
- /* now check if current entry is valid */
- if ((addr + sizeof(struct tcpa_event)) >= limit)
- return NULL;
-
- event = addr;
+ if (((converted_event_type == 0) && (converted_event_size == 0))
+ || ((addr + sizeof(struct tcpa_event) +
converted_event_size)
+ >= limit))
+ return NULL;
- converted_event_size = do_endian_conversion(event->event_size);
- converted_event_type = do_endian_conversion(event->event_type);
+ if (i++ == *pos)
+ break;
- if (((converted_event_type == 0) && (converted_event_size == 0))
- || ((addr + sizeof(struct tcpa_event) + converted_event_size)
- >= limit))
- return NULL;
+ addr += (sizeof(struct tcpa_event) + converted_event_size);
+ } while (1);
return addr;
}
--
1.8.3.1
Re: [PATCH v2] staging: wilc1000: fix cast to restricted __le32
Thank you for your review Larry > Before you send V3 Oh, v3 was already sent a few moments before your message. > Before you send V3, are you sure this is the correct fix? As "frame_type" is > input as u16, it seems to me that the frame_type member of struct > wilc_reg_frame > should be __le16, not __le32. Yes, I am confident about it. The frame_type member of struct wilc_reg_frame contains in some cases 32 bit value as you can see in function wilc_wlan_cfg_set_wid. Cast to 32 bits is also safe, due to resultant endianness. Julius
Re: knifeshack (Linux Property rights)
Your "no it does not because we are talking about software" argument is, to put it simply in a way you can understand: retarded. It shows that you, a software engineer, because you are learned in one field of endeavor, believe yourself to be "smart" and "reasonable" in unrelated fields of endeavors. You are wrong. This really shows how stupid alot of you western software-only guys are. (Also moronic is your constant disparagement of those who have to deal with the physical realities of things: the hardware guys). I have gone to lengths to attempt to teach you the foundation of licensing law, how it interacts with copyright, and how such applies to the specific facts surrounding the linux kernel; myself knowing the history of the kernel, and also being studied in US law. It doesn't seem to get through. So simply: You are not a lawyer. Do not think your "common sense" as a software engineer applies to the law. --- (On to the knifeshack analogy/story:) In the USA, the law regarding licensing of various properties is similar. The key here is that the owner simply gave permission to use his property (he did not seek payment for extending that permission). To illustrate the fact, so that non-lawyers would understand, we have used a Knife as an analogy. Also note: It is from the USA that the CoC problem is emanating, so it is right to use the law of the USA to illustrate the point (also since that's where lawsuits are most likely to occur: You do know about the USA, correct?) It doesn't matter so much, in this corner of the law, that IP is not physical property. In the area of giving permission to use it, it is treated much the same. Remember: the "Thing" that was extended to you was the permission, that is what you "have", you do not own the intellectual property you were licensed. Now, once we look at commercial licenses, things get more complicated because you paid for the license. But the key point here is that this isn't such a situation. We are not discussing commercial software licensing here. When you cursory look up information to "fact check" me, 9 times out of 10 you will be reading about the law as regards to commercial licenses where there is bargained-for consideration. Then you cite that to say that I'm wrong. (PJ made this very same mistake on this issue in 2005, she's still "cited" even though she's just a paralegal (still) and not a lawyer, and is wrong (maybe that's why she shut-up once her identity was know)). A license not coupled with an interest is revocable by the property owner. It's fairly simple. Ask yourself "did I pay linux programer-copyright-holder 7829 for permission to use his code?". No? Then you have not paid for whatever "promise" he made to you (if any). Thus you cannot bind him. And as I have shown; he never even made the promise you imagine he did. The whole counter-argument is to concoct some non-existent attached interest. The fact that we are dealing with software and not land or personal property is NOT controlling. I know you think it should be handled differently, but your uneducated opinion is not controlling law. Perhaps you would be better off with a video recorded in American to explain it all simply: Video: https://openload.co/f/mT_AH3xmIUM/TruthAboutLinuxandGPLv2__.mp4 Audio: https://ufile.io/sdhpl On 2019-01-03 12:19, MPhil. Emanoil Kotsev wrote: vsnsdua...@memeware.net wrote: On 2019-01-02 02:32, Mike Galbraith wrote: Take your medication. Don't like the story? Why what is wrong with it. Was it the entrance, the middle, or the conclusion? It simply explains licensing in a way you might find helpful, as it relates to linux. No, it does not, because you can not copy and redistribute anything but software. PLS give us a break!
Re: [PATCHv3 1/2] mm/memblock: extend the limit inferior of bottom-up after parsing hotplug attr
On Sat, Jan 05, 2019 at 11:44:50AM +0800, Baoquan He wrote:
> On 01/04/19 at 05:09pm, Mike Rapoport wrote:
> > On Thu, Jan 03, 2019 at 10:47:06AM -0800, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Wed, Jan 02, 2019 at 07:05:38PM +0200, Mike Rapoport wrote:
> > > > I agree that currently the bottom-up allocation after the kernel text
> > > > has
> > > > issues with KASLR. But this issues are not necessarily related to the
> > > > memory hotplug. Even with a single memory node, a bottom-up allocation
> > > > will
> > > > fail if KASLR would put the kernel near the end of node0.
> > > >
> > > > What I am trying to understand is whether there is a fundamental reason
> > > > to
> > > > prevent allocations from [0, kernel_start)?
> > > >
> > > > Maybe Tejun can recall why he suggested to start bottom-up allocations
> > > > from
> > > > kernel_end.
> > >
> > > That's from 79442ed189ac ("mm/memblock.c: introduce bottom-up
> > > allocation mode"). I wasn't involved in that patch, so no idea why
> > > the restrictions were added, but FWIW it doesn't seem necessary to me.
> >
> > I should have added the reference [1] at the first place :)
> > Thanks!
> >
> > [1] https://lore.kernel.org/lkml/20130904192215.gg26...@mtj.dyndns.org/
>
> With my understanding, we may not be able to discard the bottom-up
> method for the current kernel. It's related to hotplug feature when
> 'movable_node' kernel parameter is specified. With 'movable_node',
> system relies on reading hotplug information from firmware, on x86 it's
> acpi SRAT table. In the current system, we allocate memblock region
> top-down by default. However, before that hotplug information retrieving,
> there are several places of memblock allocating, top-down memblock
> allocation must break hotplug feature since it will allocate kernel data
> in movable zone which is usually at the end node on bare metal system.
I do not suggest to discard the bottom-up method, I merely suggest to allow
it to use [0, kernel_start).
> This bottom-up way is taken on many ARCHes, it works well on system if
> KASLR is not enabled. Below is the searching result in the current linux
> kernel, we can see that all ARCHes have this mechanism, except of
> arm/arm64. But now only arm64/mips/x86 have KASLR.
>
> W/o KASLR, allocating memblock region above kernle end when hotplug info
> is not parsed, looks very reasonable. Since kernel is usually put at
> lower address, e.g on x86, it's 16M. My thought is that we need do
> memblock allocation around kernel before hotplug info parsed. That is
> for system w/o KASLR, we will keep the current bottom-up way; for system
> with KASLR, we should allocate memblock region top-down just below
> kernel start.
I completely agree. I was thinking about making
memblock_find_in_range_node() to do something like
if (memblock_bottom_up()) {
bottom_up_start = max(start, kernel_end);
ret = __memblock_find_range_bottom_up(bottom_up_start, end,
size, align, nid, flags);
if (ret)
return ret;
bottom_up_start = max(start, 0);
end = kernel_start;
ret = __memblock_find_range_top_down(bottom_up_start, end,
size, align, nid, flags);
if (ret)
return ret;
}
> This issue must break hotplug, just because currently bare metal system
> need add 'nokaslr' to disable KASLR since another bug fix is under
> discussion as below, so this issue is covered up.
>
> [PATCH v14 0/5] x86/boot/KASLR: Parse ACPI table and limit KASLR to choosing
> immovable memory
> lkml.kernel.org/r/20181214093013.13370-1-fanc.f...@cn.fujitsu.com
>
> [~ ]$ git grep memblock_set_bottom_up
> arch/alpha/kernel/setup.c: memblock_set_bottom_up(true);
> arch/m68k/mm/motorola.c:memblock_set_bottom_up(true);
> arch/mips/kernel/setup.c: memblock_set_bottom_up(true);
> arch/mips/kernel/traps.c: memblock_set_bottom_up(false);
> arch/nds32/kernel/setup.c: memblock_set_bottom_up(true);
> arch/powerpc/kernel/paca.c: memblock_set_bottom_up(true);
> arch/powerpc/kernel/paca.c: memblock_set_bottom_up(false);
> arch/s390/kernel/setup.c: memblock_set_bottom_up(true);
> arch/s390/kernel/setup.c: memblock_set_bottom_up(false);
> arch/sparc/mm/init_32.c:memblock_set_bottom_up(true);
> arch/x86/kernel/setup.c:memblock_set_bottom_up(true);
> arch/x86/mm/numa.c: memblock_set_bottom_up(false);
> include/linux/memblock.h:static inline void __init
> memblock_set_bottom_up(bool enable)
>
--
Sincerely yours,
Mike.
(Video): Regarding Linux: yes you can rescind license to use your code.
One note: The audio/videos are explained in American. Those who enjoy English may read the lengthy explanations given here previously. American was chosen for the audio/video for those who do not like reading. Hopefully this choice of dialect will be most understandable for The People. Video: https://openload.co/f/mT_AH3xmIUM/TruthAboutLinuxandGPLv2__.mp4 Audio: https://ufile.io/sdhpl (Note: these will only be up for 30 days so re-post them somewhere else perhaps.)
(Video) Linux and GPLv2 license rescission: Explained in American.
Liveleak took the files down, here they are again, on a different host: Video: https://openload.co/f/mT_AH3xmIUM/TruthAboutLinuxandGPLv2__.mp4 Audio: https://ufile.io/sdhpl Spread them, since people don't like reading... The Truth about Linux GPLv2 and license rescission (revocation). (Explained in American) Information regarding the rights of the linux programmers, regarding rescission (revocation) of their granted license to use their code.
Re: [PATCH] tipc: fix memory leak in tipc_nl_compat_publ_dump
On 1/6/19 12:52 AM, Gustavo A. R. Silva wrote:
> There is a memory leak in case genlmsg_put fails.
>
> Fix this by freeing *args* before return.
>
> Addresses-Coverity-ID: 1476406 ("Resource leak")
> Fixes: 46273cf7e009 ("tipc: fix a missing check of genlmsg_put")
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Ying Xue
> ---
> net/tipc/netlink_compat.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/tipc/netlink_compat.c b/net/tipc/netlink_compat.c
> index 40f5cae623a7..77e4b2418f30 100644
> --- a/net/tipc/netlink_compat.c
> +++ b/net/tipc/netlink_compat.c
> @@ -904,8 +904,10 @@ static int tipc_nl_compat_publ_dump(struct
> tipc_nl_compat_msg *msg, u32 sock)
>
> hdr = genlmsg_put(args, 0, 0, _genl_family, NLM_F_MULTI,
> TIPC_NL_PUBL_GET);
> - if (!hdr)
> + if (!hdr) {
> + kfree_skb(args);
> return -EMSGSIZE;
> + }
>
> nest = nla_nest_start(args, TIPC_NLA_SOCK);
> if (!nest) {
>
Re: [PATCH net 1/4] umh: add exit routine for UMH process
On Sun, 6 Jan 2019 at 07:10, David Miller wrote:
>
> From: Taehee Yoo
> Date: Mon, 31 Dec 2018 01:31:43 +0900
>
> > +void exit_umh(struct task_struct *tsk)
> > +{
> > + struct umh_info *info;
> > + pid_t pid = tsk->pid;
> > +
> > + mutex_lock(_list_lock);
> > + list_for_each_entry(info, _list, list) {
>
Thank you for review!
> So this is probably too expensive of a cost for every process exit.
> The problem is that the cost will be taken even if the process is
> not a UMH.
>
Yes, I agree with you.
> I've taken my time to respond in hopes that I could come up with a
> good alternative to suggest, but so far I don't have any better ideas.
>
> I'll keep thinking about this some more, please let me know if you
> have any ideas.
Thanks a lot for spending time to think about better ideas!
How about adding a new PF_UMH flag for task_struct->flags to identify
UMH process?
By using this flag, the exit_umh() can avoid unnecessary lookups.
Thanks again.
[PATCH v2] arm64: dts: rockchip: add ROCK Pi 4 DTS support
From: Akash Gajjar
ROCK Pi 4 is RK3399 based SBC from radxa.com. board has a 1G/2G/4G lpddr4, CSI,
DSI, HDMI, OTG, USB 2.0, USB 3.0, 10/100/1000 RGMII Ethernet Phy, es8316 codec,
POE, WIFI (for Model B only), PCIE M.2 support on board.
This patch enables
- HDMI Display
- Console
- MMC, EMMC
- USB 2.0, USB-3.0
- Ethernet
Signed-off-by: Akash Gajjar
Signed-off-by: Pragnesh Patel
---
changes in v2
- hdmi regulator name correction
- replace gpio pin number with appropriate macro
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-rock-pi-4.dts| 606 ++
3 files changed, 612 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index b12958bda09c..b45296e1c20e 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -317,6 +317,11 @@ properties:
- const: radxa,rock
- const: rockchip,rk3188
+ - description: Radxa ROCK Pi 4
+items:
+ - const: radxa,rockpi4
+ - const: rockchip,rk3399
+
- description: Radxa Rock2 Square
items:
- const: radxa,rock2-square
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index de0c406c20cc..3fab0a3e4eeb 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -18,6 +18,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-scarlet-inx.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-scarlet-kd.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
new file mode 100644
index ..8a8006d49c97
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
@@ -0,0 +1,606 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Akash Gajjar
+ * Copyright (c) 2019 Pragnesh Patel
+ */
+
+/dts-v1/;
+#include
+#include
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Radxa ROCK Pi 4";
+ compatible = "radxa,rockpi4", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ vcc12v_dcin: dc-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc12v_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ vcc5v0_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_dcin>;
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PD2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwr_en>;
+ regulator-name = "vcc3v3_pcie";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_sys>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_sys>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ gpio = < RK_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_host_en>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ enable-active-high;
+ vin-supply = <_sys>;
+ };
+
+ vcc5v0_typec: vcc5v0-typec-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PA3 GPIO_ACTIVE_HIGH>;
+
Re: [PATCH 2/2] Input: rotaty-encoder - Add DT binding document
Yes, it's needed.
Even with the same encoder, adjusting steps affects rate of event generation.
(the steps defines 1 cycle of encoder rotation, and 1 cycle = 1 key event.)
On Sun, Jan 6, 2019 at 8:11 AM Dmitry Torokhov
wrote:
>
> On Sat, Jan 5, 2019 at 2:27 PM Donghoon Han wrote:
> >
> > Add DT binding document for rotary-encoder, keycode options.
> >
> > Signed-off-by: Donghoon Han
> > ---
> > .../devicetree/bindings/input/rotary-encoder.txt | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > index f99fe5cdeaec..113640079de3 100644
> > --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > @@ -12,6 +12,10 @@ Optional properties:
> > - rotary-encoder,relative-axis: register a relative axis rather than an
> >absolute one. Relative axis will only generate +1/-1 events on the input
> >device, hence no steps need to be passed.
> > +- rotary-encoder,relative-keys : generate pair of key events. This setting
> > + behaves just like relative-axis, generating key events. keycode[2]
> > + corresponds -1/1 events.
> > +- rotary-encoder,relative-keycodes : keycodes for relative-keys
> > - rotary-encoder,rollover: Automatic rollover when the rotary value becomes
> >greater than the specified steps or smaller than 0. For absolute axis
> > only.
> > - rotary-encoder,steps-per-period: Number of steps (stable states) per
> > period.
> > @@ -48,3 +52,11 @@ Example:
> > rotary-encoder,encoding = "binary";
> > rotary-encoder,rollover;
> > };
> > +
> > + rotary@2 {
> > + compatible = "rotary-encoder";
> > + gpios = < 21 0>, < 22 0>;
> > + rotary-encoder,relative-keys;
> > + rotary-encoder,relative-keycode = <103>, <108>;
> > + rotary-encoder,steps-per-period = <2>;
>
> Do you need steps for keys? They weren't required for the relative axis mode.
>
> Thanks.
>
> --
> Dmitry
--
한동훈 드림.
Re: [PATCH 1/2] Input: rotary_encoder - Support key events
input_sync() is there, at the end of the function.
static void rotary_encoder_report_event(struct rotary_encoder *encoder)
{
if (encoder->relative_axis) {
input_report_rel(encoder->input,
encoder->axis, encoder->dir);
} else if (encoder->relative_keys) {
u32 keycode = encoder->keycodes[encoder->dir > 0];
input_event(encoder->input, EV_KEY, keycode, 1);
input_event(encoder->input, EV_KEY, keycode, 0);
} else {
unsigned int pos = encoder->pos;
if (encoder->dir < 0) {
/* turning counter-clockwise */
if (encoder->rollover)
pos += encoder->steps;
if (pos)
pos--;
} else {
/* turning clockwise */
if (encoder->rollover || pos < encoder->steps)
pos++;
}
if (encoder->rollover)
pos %= encoder->steps;
encoder->pos = pos;
input_report_abs(encoder->input, encoder->axis, encoder->pos);
}
input_sync(encoder->input);
}
On Sun, Jan 6, 2019 at 8:12 AM Dmitry Torokhov
wrote:
>
> On Sat, Jan 5, 2019 at 2:27 PM Donghoon Han wrote:
> >
> > From: Steven Han
> >
> > Support generating EV_KEY pair, instead of EV_REL.
> >
> > Signed-off-by: Donghoon Han
> > ---
> > drivers/input/misc/rotary_encoder.c | 23 +--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/misc/rotary_encoder.c
> > b/drivers/input/misc/rotary_encoder.c
> > index 72eee6d55527..180e35884289 100644
> > --- a/drivers/input/misc/rotary_encoder.c
> > +++ b/drivers/input/misc/rotary_encoder.c
> > @@ -41,6 +41,8 @@ struct rotary_encoder {
> > u32 steps;
> > u32 axis;
> > bool relative_axis;
> > + bool relative_keys;
> > + u32 keycodes[2];
> > bool rollover;
> > enum rotary_encoder_encoding encoding;
> >
> > @@ -79,6 +81,10 @@ static void rotary_encoder_report_event(struct
> > rotary_encoder *encoder)
> > if (encoder->relative_axis) {
> > input_report_rel(encoder->input,
> > encoder->axis, encoder->dir);
> > + } else if (encoder->relative_keys) {
> > + u32 keycode = encoder->keycodes[encoder->dir > 0];
> > + input_event(encoder->input, EV_KEY, keycode, 1);
>
> You need input_sync() here.
>
> > + input_event(encoder->input, EV_KEY, keycode, 0);
> > } else {
> > unsigned int pos = encoder->pos;
> >
> > @@ -237,6 +243,16 @@ static int rotary_encoder_probe(struct platform_device
> > *pdev)
> > device_property_read_u32(dev, "linux,axis", >axis);
> > encoder->relative_axis =
> > device_property_read_bool(dev,
> > "rotary-encoder,relative-axis");
> > + encoder->relative_keys =
> > + device_property_read_bool(dev,
> > "rotary-encoder,relative-keys");
> > + if (encoder->relative_keys) {
> > + err = device_property_read_u32_array(dev,
> > + "rotary-encoder,relative-keycodes",
> > + encoder->keycodes, 2);
> > + if (err)
> > + dev_err(dev, "unable to get keycodes: %d\n", err);
> > + return err;
> > + }
> >
> > encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
> > if (IS_ERR(encoder->gpios)) {
> > @@ -260,9 +276,12 @@ static int rotary_encoder_probe(struct platform_device
> > *pdev)
> > input->id.bustype = BUS_HOST;
> > input->dev.parent = dev;
> >
> > - if (encoder->relative_axis)
> > + if (encoder->relative_axis) {
> > input_set_capability(input, EV_REL, encoder->axis);
> > - else
> > + } else if (encoder->relative_keys) {
> > + input_set_capability(input, EV_KEY, encoder->keycodes[0]);
> > + input_set_capability(input, EV_KEY, encoder->keycodes[1]);
> > + } else
> > input_set_abs_params(input,
> > encoder->axis, 0, encoder->steps, 0,
> > 1);
> >
> > --
> > 2.17.1
> >
>
> Thanks.
>
> --
> Dmitry
--
한동훈 드림.
[PATCH 1/1] net: bridge: fix a bug on using a neighbour cache entry without checking its state
From: JianJhen Chen
When handling DNAT'ed packets on a bridge device, the neighbour cache entry
from lookup was used without checking its state. It means that a cache entry
in the NUD_STALE state will be used directly instead of entering the NUD_DELAY
state to confirm the reachability of the neighbor.
This problem becomes worse after commit 2724680bceee ("neigh: Keep neighbour
cache entries if number of them is small enough."), since all neighbour cache
entries in the NUD_STALE state will be kept in the neighbour table as long as
the number of cache entries does not exceed the value specified in gc_thresh1.
This commit validates the state of a neighbour cache entry before using
the entry.
Signed-off-by: JianJhen Chen
Reviewed-by: JinLin Chen
---
net/bridge/br_netfilter_hooks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index b1b5e85..ed683e5 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -278,7 +278,7 @@ int br_nf_pre_routing_finish_bridge(struct net *net, struct
sock *sk, struct sk_
struct nf_bridge_info *nf_bridge = nf_bridge_info_get(skb);
int ret;
- if (neigh->hh.hh_len) {
+ if ((neigh->nud_state & NUD_CONNECTED) && neigh->hh.hh_len) {
neigh_hh_bridge(>hh, skb);
skb->dev = nf_bridge->physindev;
ret = br_handle_frame_finish(net, sk, skb);
--
2.7.4
Re: (Audio/Video): The Truth about Linux GPLv2 and license recission (revocation).
Liveleak took the files down, here they are again: Video: https://openload.co/f/mT_AH3xmIUM/TruthAboutLinuxandGPLv2__.mp4 Audio: https://ufile.io/sdhpl So hard finding "don't need your real contact info" file hosts these days. (And "real contact info" also includes a non-proxy'd IP) On 2019-01-04 14:43, Ivan Ivanov wrote: Sadly your informative videos deleted (by NSA?), could you please reupload? This could be useful for removing your source code if you disagree with Cock of Conduct пт, 4 янв. 2019 г. в 16:04, : Information regarding the rights of the linux programmers, regarding rescission (revocation) of their granted license to use their code. Video: http://www.liveleak.com/view?t=9O5vz_1546606404 ( Audio Only: ) (Part1: http://www.liveleak.com/view?t=s3Sr9_1546605652 ) (Part2: http://www.liveleak.com/view?t=aOkfS_1546605889 )
(Audio/Video) Linux and GPLv2 license rescission. (previous was removed by liveleak)
Liveleak took the files down, here they are again: Video: https://openload.co/f/mT_AH3xmIUM/TruthAboutLinuxandGPLv2__.mp4 Audio: https://ufile.io/sdhpl Spread them, since people don't like reading... The Truth about Linux GPLv2 and license rescission (revocation). Information regarding the rights of the linux programmers, regarding rescission (revocation) of their granted license to use their code. "The flow of waters, like the flow of time, like the flow of truth"
[PATCH V3] usbcore: Select only first configuration for non-UAC3 compliant devices
From: Saranya Gopal
In most of the UAC1 and UAC2 audio devices, the first
configuration is most often the best configuration.
However, with recent patch to support UAC3 configuration,
second configuration was unintentionally chosen for
some of the UAC1/2 devices that had more than one
configuration. This was because of the existing check
after the audio config check which selected any config
which had a non-vendor class. This patch fixes this issue.
Fixes: f13912d3f014 ("usbcore: Select UAC3 configuration for audio if present")
Reported-by: Con Kolivas
Signed-off-by: Saranya Gopal
Tested-by: Con Kolivas
---
Changes from V2: Added Tested-by tag
Changes from V1: Added full commit name and more SHA1 numbers in Fixes tag
drivers/usb/core/generic.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c
index 356b05c..f713cec 100644
--- a/drivers/usb/core/generic.c
+++ b/drivers/usb/core/generic.c
@@ -143,9 +143,12 @@ int usb_choose_configuration(struct usb_device *udev)
continue;
}
- if (i > 0 && desc && is_audio(desc) && is_uac3_config(desc)) {
- best = c;
- break;
+ if (i > 0 && desc && is_audio(desc)) {
+ if (is_uac3_config(desc)) {
+ best = c;
+ break;
+ }
+ continue;
}
/* From the remaining configs, choose the first one whose
--
1.9.1
Re: [GIT PULL] livepatching for 4.21
The pull request you sent on Thu, 3 Jan 2019 12:39:18 +0100 (CET): > git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1686cc1a31f45a3fd090e5d0c6fce777422e13fa Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] fbdev changes for v4.21
The pull request you sent on Fri, 4 Jan 2019 13:09:05 +0100: > https://github.com/bzolnier/linux.git tags/fbdev-v4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a8a6b1186b1a209647483c2ff81e0d59c43dbdd3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] drm next fixes for rc1
The pull request you sent on Sat, 5 Jan 2019 05:10:22 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-01-05 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0fe4e2d5cd931ad2ff99d61cfdd5c6dc0c3ec60b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PULL REQUEST] i2c for 5.0 (or how it will be called)
The pull request you sent on Fri, 4 Jan 2019 12:06:44 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-5.0 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7671c14e6aca7a816a29a85eba47d9bccb7d23ae Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Documentation fixes
The pull request you sent on Fri, 4 Jan 2019 15:02:39 -0700: > git://git.lwn.net/linux.git tags/docs-5.0-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b5aef86e089a2d85a6d627372287785d08938cbe Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] FireWire (IEEE 1394) update post v4.20
The pull request you sent on Sat, 5 Jan 2019 17:05:40 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git > firewire-update has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/15b215e5aa29993c1b0f46693a1b482296bcf08e Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] PCI changes for v4.21
The pull request you sent on Thu, 3 Jan 2019 09:05:52 -0600: > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git > tags/pci-v4.21-changes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/926b02d3eb547daa1d56cf9b586f31b270488b77 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull RDMA subsystem changes
The pull request you sent on Fri, 4 Jan 2019 05:00:10 +: > git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3954e1d0310e30e743431b58918825c4d4fe8812 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL v2] HID for 4.21
The pull request you sent on Thu, 3 Jan 2019 13:07:04 +0100 (CET): > git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cf26057a9441173ad552e90cea3344607075c9ad Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 3/3] RISC-V: Fix non-smp kernel boot on SMP systems
On 12/26/18 7:58 PM, Anup Patel wrote:
On Thu, Dec 27, 2018 at 4:39 AM Atish Patra wrote:
In non-smp configuration, hartid can be higher that NR_CPUS.
riscv_of_processor_hartid should not be compared to hartid to
NR_CPUS in that case. Moreover, this function checks all the
DT properties of a hart node. NR_CPUS comparison seems out of
place.
This only explains change in arch/riscv/kernel/cpu.c
Create separate patch for it.
Do cpuid comparison with NR_CPUs in smp setup code. Update the
Create separate patch for change in arch/riscv/kernel/smp.c
drivers to handle appropriate code as well.
Create separate patches for riscv_timer and irq-sifive-plic.c
because they will probably go via different gitrepos.
Signed-off-by: Atish Patra
---
arch/riscv/kernel/cpu.c | 4
arch/riscv/kernel/smp.c | 1 -
arch/riscv/kernel/smpboot.c | 5 +
drivers/clocksource/riscv_timer.c | 21 ++---
drivers/irqchip/irq-sifive-plic.c | 5 +
5 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index b4a7d442..251ffab6 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -34,10 +34,6 @@ int riscv_of_processor_hartid(struct device_node *node)
pr_warn("Found CPU without hart ID\n");
return -(ENODEV);
}
- if (hart >= NR_CPUS) {
- pr_info("Found hart ID %d, which is above NR_CPUs. Disabling this
hart\n", hart);
- return -(ENODEV);
- }
if (of_property_read_string(node, "status", )) {
pr_warn("CPU with hartid=%d has no \"status\" property\n",
hart);
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index 57b1383e..9ea7ac7d 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -49,7 +49,6 @@ int riscv_hartid_to_cpuid(int hartid)
return i;
pr_err("Couldn't find cpu id for hartid [%d]\n", hartid);
- BUG();
Have a separate patch with explanation about why
we don't need BUG() here.
Ok. I will split the patch into multiple ones as suggested.
Regards,
Atish
return i;
}
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index bb8cd242..05291840 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -66,6 +66,11 @@ void __init setup_smp(void)
found_boot_cpu = 1;
continue;
}
+ if (cpuid >= NR_CPUS) {
+ pr_warn("Invalid cpuid [%d] for hartid [%d]\n",
+ cpuid, hart);
+ break;
+ }
cpuid_to_hartid_map(cpuid) = hart;
set_cpu_possible(cpuid, true);
diff --git a/drivers/clocksource/riscv_timer.c
b/drivers/clocksource/riscv_timer.c
index 084e97dc..acf2af10 100644
--- a/drivers/clocksource/riscv_timer.c
+++ b/drivers/clocksource/riscv_timer.c
@@ -89,20 +89,35 @@ static int __init riscv_timer_init_dt(struct device_node *n)
struct clocksource *cs;
hartid = riscv_of_processor_hartid(n);
+ if (hartid < 0) {
+ pr_warn("Not valid hartid for node [%pOF] error = [%d]\n",
+ n, hartid);
+ return hartid;
+ }
cpuid = riscv_hartid_to_cpuid(hartid);
+ if (cpuid < 0)
+ pr_warn("Invalid cpuid for hartid [%d]\n", hartid);
+
if (cpuid != smp_processor_id())
return 0;
+ pr_err("%s: Registering clocksource cpuid [%d] hartid [%d]\n",
+ __func__, cpuid, hartid);
cs = per_cpu_ptr(_clocksource, cpuid);
- clocksource_register_hz(cs, riscv_timebase);
+ error = clocksource_register_hz(cs, riscv_timebase);
+ if (error) {
+ pr_err("RISCV timer register failed [%d] for cpu = [%d]\n",
+ error, cpuid);
+ return error;
+ }
error = cpuhp_setup_state(CPUHP_AP_RISCV_TIMER_STARTING,
"clockevents/riscv/timer:starting",
riscv_timer_starting_cpu, riscv_timer_dying_cpu);
if (error)
- pr_err("RISCV timer register failed [%d] for cpu = [%d]\n",
- error, cpuid);
+ pr_err("cpu hp setup state failed for RISCV timer [%d]\n",
+ error);
return error;
}
diff --git a/drivers/irqchip/irq-sifive-plic.c
b/drivers/irqchip/irq-sifive-plic.c
index 357e9daf..254ecd76 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -237,6 +237,11 @@ static int __init plic_init(struct device_node *node,
}
cpu = riscv_hartid_to_cpuid(hartid);
+ if (cpu < 0) {
+ pr_warn("Invalid cpuid for context %d\n", i);
+ continue;
+
Re: [PATCH 2/3] RISC-V: Move cpuid to hartid mapping to SMP.
On 12/26/18 7:38 PM, Anup Patel wrote:
On Thu, Dec 27, 2018 at 4:39 AM Atish Patra wrote:
Currently, logical CPU id to physical hartid mapping is
defined for both smp and non-smp configurations. This
is not required as we need this only for smp configuration.
The mapping function can define directly boot_cpu_hartid
for non-smp usecase.
The reverse mapping function i.e. hartid to cpuid can be called
for any valid but not booted harts. So it should return default
cpu 0 only if it is a boot hartid
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/smp.h | 13 +++--
arch/riscv/kernel/setup.c| 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index 41aa73b4..8f30300f 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -22,12 +22,13 @@
/*
* Mapping between linux logical cpu index and hartid.
*/
-extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
-#define cpuid_to_hartid_map(cpu)__cpuid_to_hartid_map[cpu]
+extern unsigned long boot_cpu_hartid;
struct seq_file;
#ifdef CONFIG_SMP
+extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
+#define cpuid_to_hartid_map(cpu)__cpuid_to_hartid_map[cpu]
/* print IPI stats */
void show_ipi_stats(struct seq_file *p, int prec);
@@ -58,7 +59,15 @@ static inline void show_ipi_stats(struct seq_file *p, int
prec)
static inline int riscv_hartid_to_cpuid(int hartid)
{
+ if (hartid == boot_cpu_hartid)
return 0;
+ else
+ return -1;
+}
+static inline unsigned long cpuid_to_hartid_map(int cpu)
+{
+
+ return boot_cpu_hartid;
}
static inline void riscv_cpuid_to_hartid_mask(const struct cpumask *in,
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 2c290e6a..bd4d7b85 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -83,6 +83,7 @@ EXPORT_SYMBOL(empty_zero_page);
atomic_t hart_lottery;
unsigned long boot_cpu_hartid;
+#ifdef CONFIG_SMP
unsigned long __cpuid_to_hartid_map[NR_CPUS] = {
[0 ... NR_CPUS-1] = INVALID_HARTID
};
@@ -91,6 +92,7 @@ void __init smp_setup_processor_id(void)
{
cpuid_to_hartid_map(0) = boot_cpu_hartid;
}
+#endif
Please move __cpuid_to_hartid_map[] and smp_setup_processor_id()
to arch/riscv/kernel/smp.c
Will do. Thanks for the review.
Otherwise, looks good to me.
Reviewed-by: Anup Patel
Regards,
Atish
[GIT PULL] more Kbuild updates for v4.21
Hi Linus,
Here are late Kbuild updates.
I am sending this pull request in the last minute
to avoid conflicts from tree-wide cleanups such as
jump_label, generic-y.
Please pull!
The following changes since commit 5c4a60831aa6d937cec9cf17aef8eb6c1851bfcd:
Merge branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux (2019-01-05
16:07:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v4.21-3
for you to fetch changes up to d86271af64602e7c86c003b27f27c7216706ff96:
kconfig: rename generated .*conf-cfg to *conf-cfg (2019-01-06 10:47:09 +0900)
Kbuild late updates for v4.21
- improve boolinit.cocci and use_after_iter.cocci semantic patches
- fix alignment for kallsyms
- move 'asm goto' compiler test to Kconfig and clean up jump_label
CONFIG option
- generate asm-generic wrappers automatically if arch does not implement
mandatory UAPI headers
- remove redundant generic-y defines
- misc cleanups
Julia Lawall (2):
scripts: coccinelle: check for redeclaration
scripts: coccinelle: boolinit: drop warnings on named constants
Masahiro Yamada (15):
nios2: remove unneeded HAS_DMA define
nds32: remove redundant kernel-space generic-y
kconfig: remove unused "file" field of yylval union
jump_label: move 'asm goto' support test to Kconfig
kbuild: remove UIMAGE_IN and UIMAGE_OUT
kbuild: clean up rule_dtc_dt_yaml
kbuild: remove redundant target cleaning on failure
kbuild: change filechk to surround the given command with { }
riscv: remove redundant kernel-space generic-y
arch: remove stale comments "UAPI Header export list"
kbuild: generate asm-generic wrappers if mandatory headers are missing
arch: remove redundant UAPI generic-y defines
kbuild: use assignment instead of define ... endef for filechk_* rules
kbuild: remove unnecessary stubs for archheader and archscripts
kconfig: rename generated .*conf-cfg to *conf-cfg
Mathias Krause (1):
kallsyms: lower alignment on ARM
Documentation/kbuild/makefiles.txt| 9 ++---
Kbuild| 4 +---
Makefile | 22 +-
arch/Kconfig | 1 +
arch/alpha/include/uapi/asm/Kbuild| 7 ---
arch/arc/include/uapi/asm/Kbuild | 25
-
arch/arm/boot/Makefile| 2 +-
arch/arm/boot/compressed/Makefile | 2 +-
arch/arm/include/uapi/asm/Kbuild | 18 --
arch/arm/kernel/jump_label.c | 4
arch/arm/tools/Makefile | 3 +--
arch/arm64/include/uapi/asm/Kbuild| 18 --
arch/arm64/kernel/jump_label.c| 4
arch/c6x/include/uapi/asm/Kbuild | 27
---
arch/csky/include/uapi/asm/Kbuild | 27
---
arch/h8300/include/uapi/asm/Kbuild| 27
---
arch/hexagon/include/uapi/asm/Kbuild | 24
arch/ia64/include/uapi/asm/Kbuild | 7 ---
arch/m68k/include/uapi/asm/Kbuild | 20
arch/microblaze/include/uapi/asm/Kbuild | 26
--
arch/mips/include/uapi/asm/Kbuild | 3 ---
arch/mips/kernel/jump_label.c | 4
arch/nds32/include/asm/Kbuild | 10 --
arch/nds32/include/uapi/asm/Kbuild| 26
--
arch/nios2/Kconfig| 3 ---
arch/nios2/include/uapi/asm/Kbuild| 26
--
arch/openrisc/include/uapi/asm/Kbuild | 28
arch/parisc/include/uapi/asm/Kbuild | 7 ---
arch/powerpc/include/asm/asm-prototypes.h | 2 +-
arch/powerpc/include/uapi/asm/Kbuild | 7 ---
arch/powerpc/kernel/jump_label.c | 2 --
arch/powerpc/platforms/powernv/opal-tracepoints.c | 2 +-
arch/powerpc/platforms/powernv/opal-wrappers.S| 2 +-
arch/powerpc/platforms/pseries/hvCall.S | 4 ++--
arch/powerpc/platforms/pseries/lpar.c | 2 +-
arch/riscv/include/asm/Kbuild | 25
-
arch/riscv/include/uapi/asm/Kbuild| 28
arch/s390/include/uapi/asm/Kbuild | 16
arch/s390/kernel/Makefile | 3 ++-
arch/s390/kernel/jump_label.c
Re: [PATCH 1/5] riscv: remove redundant kernel-space generic-y
On Thu, Jan 3, 2019 at 10:32 AM Masahiro Yamada wrote: > > This commit removes redundant generic-y defines in > arch/riscv/include/asm/Kbuild. > > [1] It is redundant to define the same generic-y in both > arch/$(ARCH)/include/asm/Kbuild and > arch/$(ARCH)/include/uapi/asm/Kbuild. > > Remove the following generic-y: > > errno.h > fcntl.h > ioctl.h > ioctls.h > ipcbuf.h > mman.h > msgbuf.h > param.h > poll.h > posix_types.h > resource.h > sembuf.h > setup.h > shmbuf.h > signal.h > socket.h > sockios.h > stat.h > statfs.h > swab.h > termbits.h > termios.h > types.h > > [2] It is redundant to define generic-y when arch-specific > implementation exists in arch/$(ARCH)/include/asm/*.h > > Remove the following generic-y: > > cacheflush.h > module.h > > Signed-off-by: Masahiro Yamada > --- > > Changes in v2: > - rebase on Linus' tree Patch 1-4, applied to linux-kbuild. > arch/riscv/include/asm/Kbuild | 25 - > 1 file changed, 25 deletions(-) > > diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild > index 6a646d9..cccd12c 100644 > --- a/arch/riscv/include/asm/Kbuild > +++ b/arch/riscv/include/asm/Kbuild > @@ -1,5 +1,4 @@ > generic-y += bugs.h > -generic-y += cacheflush.h > generic-y += checksum.h > generic-y += compat.h > generic-y += cputime.h > @@ -9,16 +8,11 @@ generic-y += dma.h > generic-y += dma-contiguous.h > generic-y += dma-mapping.h > generic-y += emergency-restart.h > -generic-y += errno.h > generic-y += exec.h > generic-y += fb.h > -generic-y += fcntl.h > generic-y += hardirq.h > generic-y += hash.h > generic-y += hw_irq.h > -generic-y += ioctl.h > -generic-y += ioctls.h > -generic-y += ipcbuf.h > generic-y += irq_regs.h > generic-y += irq_work.h > generic-y += kdebug.h > @@ -27,34 +21,15 @@ generic-y += kvm_para.h > generic-y += local.h > generic-y += local64.h > generic-y += mm-arch-hooks.h > -generic-y += mman.h > -generic-y += module.h > -generic-y += msgbuf.h > generic-y += mutex.h > -generic-y += param.h > generic-y += percpu.h > -generic-y += poll.h > -generic-y += posix_types.h > generic-y += preempt.h > -generic-y += resource.h > generic-y += scatterlist.h > generic-y += sections.h > -generic-y += sembuf.h > generic-y += serial.h > -generic-y += setup.h > -generic-y += shmbuf.h > generic-y += shmparam.h > -generic-y += signal.h > -generic-y += socket.h > -generic-y += sockios.h > -generic-y += stat.h > -generic-y += statfs.h > -generic-y += swab.h > -generic-y += termbits.h > -generic-y += termios.h > generic-y += topology.h > generic-y += trace_clock.h > -generic-y += types.h > generic-y += unaligned.h > generic-y += user.h > generic-y += vga.h > -- > 2.7.4 > -- Best Regards Masahiro Yamada
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 5, 2019 at 4:22 PM Linus Torvalds
wrote:
>
> But I think my patch to just rip out all that page lookup, and just
> base it on the page table state has the fundamental advantage that it
> gets rid of code. Maybe I should jst commit it, and see if anything
> breaks? We do have options in case things break, and then we'd at
> least know who cares (and perhaps a lot more information of _why_ they
> care).
Slightly updated patch in case somebody wants to try things out.
Also, any comments about the pmd_trans_unstable() case?
Linus
mm/mincore.c | 94 +---
1 file changed, 13 insertions(+), 81 deletions(-)
diff --git a/mm/mincore.c b/mm/mincore.c
index 218099b5ed31..f0f91461a9f4 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -42,72 +42,14 @@ static int mincore_hugetlb(pte_t *pte, unsigned long hmask, unsigned long addr,
return 0;
}
-/*
- * Later we can get more picky about what "in core" means precisely.
- * For now, simply check to see if the page is in the page cache,
- * and is up to date; i.e. that no page-in operation would be required
- * at this time if an application were to map and access this page.
- */
-static unsigned char mincore_page(struct address_space *mapping, pgoff_t pgoff)
-{
- unsigned char present = 0;
- struct page *page;
-
- /*
- * When tmpfs swaps out a page from a file, any process mapping that
- * file will not get a swp_entry_t in its pte, but rather it is like
- * any other file mapping (ie. marked !present and faulted in with
- * tmpfs's .fault). So swapped out tmpfs mappings are tested here.
- */
-#ifdef CONFIG_SWAP
- if (shmem_mapping(mapping)) {
- page = find_get_entry(mapping, pgoff);
- /*
- * shmem/tmpfs may return swap: account for swapcache
- * page too.
- */
- if (xa_is_value(page)) {
- swp_entry_t swp = radix_to_swp_entry(page);
- page = find_get_page(swap_address_space(swp),
- swp_offset(swp));
- }
- } else
- page = find_get_page(mapping, pgoff);
-#else
- page = find_get_page(mapping, pgoff);
-#endif
- if (page) {
- present = PageUptodate(page);
- put_page(page);
- }
-
- return present;
-}
-
-static int __mincore_unmapped_range(unsigned long addr, unsigned long end,
-struct vm_area_struct *vma, unsigned char *vec)
-{
- unsigned long nr = (end - addr) >> PAGE_SHIFT;
- int i;
-
- if (vma->vm_file) {
- pgoff_t pgoff;
-
- pgoff = linear_page_index(vma, addr);
- for (i = 0; i < nr; i++, pgoff++)
- vec[i] = mincore_page(vma->vm_file->f_mapping, pgoff);
- } else {
- for (i = 0; i < nr; i++)
- vec[i] = 0;
- }
- return nr;
-}
-
static int mincore_unmapped_range(unsigned long addr, unsigned long end,
struct mm_walk *walk)
{
- walk->private += __mincore_unmapped_range(addr, end,
- walk->vma, walk->private);
+ unsigned char *vec = walk->private;
+ unsigned long nr = (end - addr) >> PAGE_SHIFT;
+
+ memset(vec, 0, nr);
+ walk->private += nr;
return 0;
}
@@ -127,8 +69,9 @@ static int mincore_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
goto out;
}
+ /* We'll consider a THP page under construction to be there */
if (pmd_trans_unstable(pmd)) {
- __mincore_unmapped_range(addr, end, vma, vec);
+ memset(vec, 1, nr);
goto out;
}
@@ -137,28 +80,17 @@ static int mincore_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
pte_t pte = *ptep;
if (pte_none(pte))
- __mincore_unmapped_range(addr, addr + PAGE_SIZE,
- vma, vec);
+ *vec = 0;
else if (pte_present(pte))
*vec = 1;
else { /* pte is a swap entry */
swp_entry_t entry = pte_to_swp_entry(pte);
- if (non_swap_entry(entry)) {
-/*
- * migration or hwpoison entries are always
- * uptodate
- */
-*vec = 1;
- } else {
-#ifdef CONFIG_SWAP
-*vec = mincore_page(swap_address_space(entry),
- swp_offset(entry));
-#else
-WARN_ON(1);
-*vec = 1;
-#endif
- }
+ /*
+ * migration or hwpoison entries are always
+ * uptodate
+ */
+ *vec = !!non_swap_entry(entry);
}
vec++;
}
Re: [PATCH] scripts: coccinelle: boolinit: drop warnings on named constants
On Sat, Dec 29, 2018 at 10:14 PM Julia Lawall wrote:
>
> Coccinelle doesn't always have access to the values of named
> (#define) constants, and they may likely often be bound to true
> and false values anyway, resulting in false positives. So stop
> warning about them.
>
> Signed-off-by: Julia Lawall
Applied to linux-kbuild. Thanks!
> ---
> scripts/coccinelle/misc/boolinit.cocci |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/scripts/coccinelle/misc/boolinit.cocci
> b/scripts/coccinelle/misc/boolinit.cocci
> index b0584a3..aabb581 100644
> --- a/scripts/coccinelle/misc/boolinit.cocci
> +++ b/scripts/coccinelle/misc/boolinit.cocci
> @@ -136,9 +136,14 @@ position p1;
> @r4 depends on !patch@
> bool b;
> position p2;
> +identifier i;
> constant c != {0,1};
> @@
> +(
> + b = i
> +|
> *b@p2 = c
> +)
>
> @script:python depends on org@
> p << r1.p;
>
--
Best Regards
Masahiro Yamada
Re: [PATCH] scripts/coccinelle: check for redeclaration
On Sat, Dec 29, 2018 at 10:32 AM Julia Lawall wrote: > > Avoid reporting on the use of an iterator index variable when > the variable is redeclared. > > Signed-off-by: Julia Lawall > > --- Applied to linux-kbuild. Thanks! > scripts/coccinelle/iterators/use_after_iter.cocci |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/scripts/coccinelle/iterators/use_after_iter.cocci > b/scripts/coccinelle/iterators/use_after_iter.cocci > index ce8cc9c..66a1140 100644 > --- a/scripts/coccinelle/iterators/use_after_iter.cocci > +++ b/scripts/coccinelle/iterators/use_after_iter.cocci > @@ -35,6 +35,7 @@ iterator name hlist_for_each_entry_from; > iterator name hlist_for_each_entry_safe; > statement S; > position p1,p2; > +type T; > @@ > > ( > @@ -125,6 +126,8 @@ sizeof(<+...c...+>) > | > >member > | > +T c; > +| > c = E > | > *c@p2 > -- Best Regards Masahiro Yamada
Re: [GIT PULL 1/4] Kbuild updates for v4.21
Hi Linus, On Sun, Jan 6, 2019 at 5:44 AM Linus Torvalds wrote: > > On Sat, Jan 5, 2019 at 12:39 PM Sam Ravnborg wrote: > > > > Not exactly what you ask for - but we have make V=2 > > Yeah, that's certainly more convenient than "make --debug". > > That said, I was more thinking of not any particular "oh, it's > recompiling everything" situation (by then it's too late, obviously), > but if somebody has been looking at tools for finding and maybe > breaking some of our deeper include chains. > > I know it has come up before (the x86 people did the > split some years ago) and then it was all manual. > But I was kind of hoping that maybe some of the kbuild people had > looked at this? Sorry, I do not know more information than Sam provided. I got rid of some unneeded header inclusions in the past, but my work was also manual. -- Best Regards Masahiro Yamada
Re: [PATCH v2 1/2] virtio-balloon: tweak config_changed implementation
On Sat, Jan 05, 2019 at 03:32:44AM +, Wang, Wei W wrote:
> On Friday, January 4, 2019 11:45 PM, Michael S. Tsirkin wrote:
> > > struct virtio_balloon {
> > > struct virtio_device *vdev;
> > > struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
> > > @@ -77,6 +81,8 @@ struct virtio_balloon {
> > > /* Prevent updating balloon when it is being canceled. */
> > > spinlock_t stop_update_lock;
> > > bool stop_update;
> > > + /* Bitmap to indicate if reading the related config fields are needed
> > */
> > > + unsigned long config_read_bitmap;
> > >
> > > /* The list of allocated free pages, waiting to be given back to mm */
> > > struct list_head free_page_list;
> >
> > It seems that you never initialize this bitmap. Probably harmless here but
> > generally using uninitialized memory isn't good.
>
> We've used kzalloc to allocate the vb struct, so it's already 0-initialized :)
Ah ok. We do explicitly init other fields like stop_update so
it seems cleaner to init this one too though.
> > > +
> > > static int send_free_pages(struct virtio_balloon *vb) {
> > > int err;
> > > @@ -620,6 +630,7 @@ static int send_free_pages(struct virtio_balloon *vb)
> > >* stop the reporting.
> > >*/
> > > cmd_id_active = virtio32_to_cpu(vb->vdev, vb-
> > >cmd_id_active);
> > > + virtio_balloon_read_cmd_id_received(vb);
>
>
> [1]
>
>
> > > if (cmd_id_active != vb->cmd_id_received)
> > > break;
> > >
> > > @@ -637,11 +648,9 @@ static int send_free_pages(struct virtio_balloon
> > *vb)
> > > return 0;
> > > }
> > >
> > > -static void report_free_page_func(struct work_struct *work)
> > > +static void virtio_balloon_report_free_page(struct virtio_balloon
> > > +*vb)
> > > {
> > > int err;
> > > - struct virtio_balloon *vb = container_of(work, struct virtio_balloon,
> > > - report_free_page_work);
> > > struct device *dev = >vdev->dev;
> > >
> > > /* Start by sending the received cmd id to host with an outbuf. */
> > > @@ -659,6 +668,22 @@ static void report_free_page_func(struct
> > work_struct *work)
> > > dev_err(dev, "Failed to send a stop id, err = %d\n", err); }
> > >
> > > +static void report_free_page_func(struct work_struct *work) {
> > > + struct virtio_balloon *vb = container_of(work, struct virtio_balloon,
> > > + report_free_page_work);
> > > +
> > > + virtio_balloon_read_cmd_id_received(vb);
> >
> > This will not achieve what you are trying to do, which is cancel reporting
> > if it's
> > in progress.
> >
> > You need to re-read each time you compare to cmd_id_active.
>
> Yes, already did, please see [1] above
Oh right. Sorry.
>
> > An API similar to
> > u32 virtio_balloon_cmd_id_received(vb)
> > seems to be called for, and I would rename cmd_id_received to
> > cmd_id_received_cache to make sure we caught all users.
> >
>
> I'm not sure about adding "cache" here, cmd_id_received refers to the cmd id
> that the driver just received from the device. There is one called
> "cmd_id_active" which
> is the one that the driver is actively using.
> So cmd_id_received is already a "cache" to " cmd_id_active " in some sense.
>
> Best,
> Wei
The point is that any access to cmd_id_received should first call
virtio_balloon_read_cmd_id_received. So a better API is
to have virtio_balloon_read_cmd_id_received return the value
instead of poking at cmd_id_received afterwards.
Renaming cmd_id_received will help make sure all no
call sites were missed and help stress it's never used directly.
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 5, 2019 at 4:11 PM Matthew Wilcox wrote: > > FreeBSD claims to have a manpage from SunOS 4.1.3 with mincore (!) > > https://www.freebsd.org/cgi/man.cgi?query=mincore=0=0=SunOS+4.1.3=default=html > > DESCRIPTION >mincore() returns the primary memory residency status of pages in the >address space covered by mappings in the range [addr, addr + len). It's still not clear that "primary memory residency status" actually means. Does it mean "mapped", or does it mean "exists in caches and doesn't need IO". I don't even know what kind of caches SunOS 4.1.3 had. The Linux implementation depends on the page cache, and wouldn't work (at least not very well) in a system that has a traditional disk buffer cache. Anyway, I guess it's mostly moot. From a "does this cause regressions" standpoint, the only thing that matters is really whatever Linux programs that have used this since it was introduced 18+ years ago. But I think my patch to just rip out all that page lookup, and just base it on the page table state has the fundamental advantage that it gets rid of code. Maybe I should jst commit it, and see if anything breaks? We do have options in case things break, and then we'd at least know who cares (and perhaps a lot more information of _why_ they care). Linus
Re: [GIT PULL v2] Thermal-SoC management updates for v4.21-rc1
The pull request you sent on Wed, 2 Jan 2019 12:05:33 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c280230254635da33703dd8f4a10cad23f640fb0 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 05, 2019 at 03:39:10PM -0800, Linus Torvalds wrote: > On Sat, Jan 5, 2019 at 3:16 PM Linus Torvalds > wrote: > > > > It goes back to forever, it looks like. I can't find a reason. > > mincore() was originally added in 2.3.52pre3, it looks like. Around > 2000 or so. But sadly before the BK history. > > And that comment about > > "Later we can get more picky about what "in core" means precisely." > > that still exists above mincore_page() goes back to the original patch. FreeBSD claims to have a manpage from SunOS 4.1.3 with mincore (!) https://www.freebsd.org/cgi/man.cgi?query=mincore=0=0=SunOS+4.1.3=default=html DESCRIPTION mincore() returns the primary memory residency status of pages in the address space covered by mappings in the range [addr, addr + len). The status is returned as a char-per-page in the character array referenced by *vec (which the system assumes to be large enough to encompass all the pages in the address range). The least significant bit of each character is set to 1 to indicate that the referenced page is in pri- mary memory, 0 if it is not. The settings of other bits in each char- acter is undefined and may contain other information in the future.
[PATCH v3 4/4] rtlwifi: Don't clear num_rx_inperiod too early
This patch moves the clearing of rtlpriv->link_info.num_rx_inperiod in rtl_watchdog_wq_callback a few lines down. This is necessary since it is still used in the "AP off" detection code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod as well for consistency. Signed-off-by: Bernd Edlinger --- v2: Improved patch description. v3: Make the title fit in one line. --- drivers/net/wireless/realtek/rtlwifi/base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c index ef9b502..7aa68fe 100644 --- a/drivers/net/wireless/realtek/rtlwifi/base.c +++ b/drivers/net/wireless/realtek/rtlwifi/base.c @@ -2172,8 +2172,6 @@ void rtl_watchdog_wq_callback(void *data) ; } - rtlpriv->link_info.num_rx_inperiod = 0; - rtlpriv->link_info.num_tx_inperiod = 0; for (tid = 0; tid <= 7; tid++) rtlpriv->link_info.tidtx_inperiod[tid] = 0; @@ -2236,6 +2234,8 @@ void rtl_watchdog_wq_callback(void *data) rtlpriv->btcoexist.btc_info.in_4way = false; } + rtlpriv->link_info.num_rx_inperiod = 0; + rtlpriv->link_info.num_tx_inperiod = 0; rtlpriv->link_info.bcn_rx_inperiod = 0; /* <6> scan list */ -- 1.9.1
[PATCH v3 3/4] rtl8723ae: Re-introduce the adaptive rate control
This re-introduces the function rtl8723e_dm_refresh_rate_adaptive_mask.
This function was present in a previous version of the code base,
it works just fine for me -- as long as it is not using stale data.
Unlike the original version of this function it avoids using
dm.undec_sm_pwdb when no beacon was received.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
v2: Improve patch description.
v3: Improve patch description, mention that dm.undec_sm_pwdb
is not used when no beacon received.
Make the title fit in one line.
---
.../net/wireless/realtek/rtlwifi/rtl8723ae/dm.c| 87 +-
1 file changed, 85 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
index 902b944..acfd54c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
@@ -673,7 +673,7 @@ void rtl8723e_dm_check_txpower_tracking(struct ieee80211_hw
*hw)
void rtl8723e_dm_init_rate_adaptive_mask(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
- struct rate_adaptive *p_ra = &(rtlpriv->ra);
+ struct rate_adaptive *p_ra = >ra;
p_ra->ratr_state = DM_RATR_STA_INIT;
p_ra->pre_ratr_state = DM_RATR_STA_INIT;
@@ -685,6 +685,89 @@ void rtl8723e_dm_init_rate_adaptive_mask(struct
ieee80211_hw *hw)
}
+void rtl8723e_dm_refresh_rate_adaptive_mask(struct ieee80211_hw *hw)
+{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+ struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
+ struct rate_adaptive *p_ra = >ra;
+ u32 low_rssithresh_for_ra, high_rssithresh_for_ra;
+ struct ieee80211_sta *sta = NULL;
+
+ if (is_hal_stop(rtlhal)) {
+ RT_TRACE(rtlpriv, COMP_RATE, DBG_LOUD,
+" driver is going to unload\n");
+ return;
+ }
+
+ if (!rtlpriv->dm.useramask) {
+ RT_TRACE(rtlpriv, COMP_RATE, DBG_LOUD,
+" driver does not control rate adaptive mask\n");
+ return;
+ }
+
+ if (mac->link_state == MAC80211_LINKED &&
+ mac->opmode == NL80211_IFTYPE_STATION) {
+ switch (p_ra->pre_ratr_state) {
+ case DM_RATR_STA_HIGH:
+ high_rssithresh_for_ra = 50;
+ low_rssithresh_for_ra = 20;
+ break;
+ case DM_RATR_STA_MIDDLE:
+ high_rssithresh_for_ra = 55;
+ low_rssithresh_for_ra = 20;
+ break;
+ case DM_RATR_STA_LOW:
+ high_rssithresh_for_ra = 60;
+ low_rssithresh_for_ra = 25;
+ break;
+ default:
+ high_rssithresh_for_ra = 50;
+ low_rssithresh_for_ra = 20;
+ break;
+ }
+
+ if (rtlpriv->link_info.bcn_rx_inperiod == 0)
+ switch (p_ra->pre_ratr_state) {
+ case DM_RATR_STA_HIGH:
+ default:
+ p_ra->ratr_state = DM_RATR_STA_MIDDLE;
+ break;
+ case DM_RATR_STA_MIDDLE:
+ case DM_RATR_STA_LOW:
+ p_ra->ratr_state = DM_RATR_STA_LOW;
+ break;
+ }
+ else if (rtlpriv->dm.undec_sm_pwdb > high_rssithresh_for_ra)
+ p_ra->ratr_state = DM_RATR_STA_HIGH;
+ else if (rtlpriv->dm.undec_sm_pwdb > low_rssithresh_for_ra)
+ p_ra->ratr_state = DM_RATR_STA_MIDDLE;
+ else
+ p_ra->ratr_state = DM_RATR_STA_LOW;
+
+ if (p_ra->pre_ratr_state != p_ra->ratr_state) {
+ RT_TRACE(rtlpriv, COMP_RATE, DBG_LOUD,
+"RSSI = %ld\n",
+rtlpriv->dm.undec_sm_pwdb);
+ RT_TRACE(rtlpriv, COMP_RATE, DBG_LOUD,
+"RSSI_LEVEL = %d\n", p_ra->ratr_state);
+ RT_TRACE(rtlpriv, COMP_RATE, DBG_LOUD,
+"PreState = %d, CurState = %d\n",
+p_ra->pre_ratr_state, p_ra->ratr_state);
+
+ rcu_read_lock();
+ sta = rtl_find_sta(hw, mac->bssid);
+ if (sta)
+ rtlpriv->cfg->ops->update_rate_tbl(hw, sta,
+ p_ra->ratr_state,
+ true);
+ rcu_read_unlock();
+
+
[PATCH v3 2/4] rtl8723ae: Dont use old data for input gain control
When no beacon was received, the value in dm.undec_sm_pwdb is most
likely out of date and should not be used to adjust the input path.
Assume instead that the signal level is low.
Fix the state machine in rtl8723e_dm_cck_packet_detection_thresh
which did not clear pre_cck_fa_state when changing cur_cck_pd_state
from CCK_PD_STAGE_LOWRSSI/CCK_FA_STAGE_LOW to CCK_PD_STAGE_HIGHRSSI
and back again to CCK_PD_STAGE_LOWRSSI/CCK_FA_STAGE_LOW, the register
RCCK0_CCA not written to 0x83 on the second change.
Explicitly initialize pre_cck_fa_state/cur_cck_fa_state in
rtl_dm_diginit.
Signed-off-by: Bernd Edlinger
---
v2: Improved patch description.
v3: Make the title fit in one line.
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 4bf7967..ce23339 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1957,5 +1957,7 @@ void rtl_dm_diginit(struct ieee80211_hw *hw, u32
cur_igvalue)
dm_digtable->bt30_cur_igi = 0x32;
dm_digtable->pre_cck_pd_state = CCK_PD_STAGE_MAX;
dm_digtable->cur_cck_pd_state = CCK_PD_STAGE_LOWRSSI;
+ dm_digtable->pre_cck_fa_state = 0;
+ dm_digtable->cur_cck_fa_state = 0;
}
EXPORT_SYMBOL(rtl_dm_diginit);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
index 42a6fba..902b944 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c
@@ -151,8 +151,14 @@ static u8 rtl8723e_dm_initial_gain_min_pwdb(struct
ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct dig_t *dm_digtable = >dm_digtable;
+ struct rtl_mac *mac = rtl_mac(rtlpriv);
long rssi_val_min = 0;
+ if (mac->link_state == MAC80211_LINKED &&
+ mac->opmode == NL80211_IFTYPE_STATION &&
+ rtlpriv->link_info.bcn_rx_inperiod == 0)
+ return 0;
+
if ((dm_digtable->curmultista_cstate == DIG_MULTISTA_CONNECT) &&
(dm_digtable->cursta_cstate == DIG_STA_CONNECT)) {
if (rtlpriv->dm.entry_min_undec_sm_pwdb != 0)
@@ -417,6 +423,8 @@ static void rtl8723e_dm_cck_packet_detection_thresh(struct
ieee80211_hw *hw)
} else {
rtl_set_bbreg(hw, RCCK0_CCA, MASKBYTE2, 0xcd);
rtl_set_bbreg(hw, RCCK0_SYSTEM, MASKBYTE1, 0x47);
+ dm_digtable->pre_cck_fa_state = 0;
+ dm_digtable->cur_cck_fa_state = 0;
}
dm_digtable->pre_cck_pd_state = dm_digtable->cur_cck_pd_state;
--
1.9.1
[PATCH v3 1/4] rtl8723ae: Take the FW LPS mode handling out
This appears to trigger a firmware bug and causes severe
problems with rtl8723ae PCI devices.
When the power save mode is activated for longer periods
of time the firmware stops to receive any packets.
This problem was exposed by commit 873ffe154ae0 ("rtlwifi:
Fix logic error in enter/exit power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
v2: Adjust the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
the whole code, so it can be easily re-activated once a firmware
update is available.
v3: Make the title fit in one line.
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
index 07b82700d1..3103151 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c
@@ -266,8 +266,8 @@ static bool is_fw_header(struct rtlwifi_firmware_header
*hdr)
static struct rtl_mod_params rtl8723e_mod_params = {
.sw_crypto = false,
.inactiveps = true,
- .swctrl_lps = false,
- .fwctrl_lps = true,
+ .swctrl_lps = true,
+ .fwctrl_lps = false,
.aspm_support = 1,
.debug_level = 0,
.debug_mask = 0,
@@ -395,8 +395,8 @@ static bool is_fw_header(struct rtlwifi_firmware_header
*hdr)
bool, 0444);
MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
-MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
-MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 1)\n");
+MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 1)\n");
+MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 0)\n");
MODULE_PARM_DESC(msi, "Set to 1 to use MSI interrupts mode (default 0)\n");
MODULE_PARM_DESC(aspm, "Set to 1 to enable ASPM (default 1)\n");
MODULE_PARM_DESC(debug_level, "Set debug level (0-5) (default 0)");
--
1.9.1
[PATCH v3 0/4] rtlwifi: Fix issues with rtl8723ae
Currently the rtl8723ae driver is broken (since v4.7). Connection to AP is lost very often, especially when the signal level is not very good. The main issue is the power save mode is basically not working, and seems to trigger a firmware bug. So I had to take out the FW LPS mode handling. While debugging the driver I found a couple related issues, for instance that the signal level in dm.undec_sm_pwdb is no longer accurate (may be even much too high) when no more packets are received, and it increases the likelihood to receive something if the input gain is set to maximum. The patch was tested with the rtl8723ae PCI card in my laptop against a FRITZ!Box 7590 AP -- the WiFi connection works now very reliable for me. ChangeLog: v2: Adjusts the defaults of swlps and fwlps module parameters to match the firmware capabilities instead of removing the whole code, so it can be easily re-activated once a firmware update is available. v3: Make the title of each patch fit in one line. Bernd Edlinger (4): rtl8723ae: Take the FW LPS mode handling out rtl8723ae: Dont use old data for input gain control rtl8723ae: Re-introduce the adaptive rate control rtlwifi: Don't clear num_rx_inperiod too early drivers/net/wireless/realtek/rtlwifi/base.c| 4 +- drivers/net/wireless/realtek/rtlwifi/core.c| 2 + .../net/wireless/realtek/rtlwifi/rtl8723ae/dm.c| 95 +- .../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c| 8 +- 4 files changed, 101 insertions(+), 8 deletions(-) -- 1.9.1
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 5, 2019 at 3:16 PM Linus Torvalds wrote: > > It goes back to forever, it looks like. I can't find a reason. mincore() was originally added in 2.3.52pre3, it looks like. Around 2000 or so. But sadly before the BK history. And that comment about "Later we can get more picky about what "in core" means precisely." that still exists above mincore_page() goes back to the original patch. Linus
Re: [PATCH 3/5] doc: networking: update references to files describing offloads
On 05. Jan (Saturday) v 14:15:16 -0800 2019, David Miller wrote:
> From: Otto Sabart
> Date: Fri, 4 Jan 2019 11:42:29 +0100
>
> > Update reference to checksum-offloads.rst file which was converted into
> > RST.
> >
> > Whole kernel code was grepped for references using:
> > $ grep -r "\(segmentation\|checksum\)-offloads.txt" .
> >
> > There should be no other references
> > to {segmentation,checksum}-offloads.txt files.
> >
> > Signed-off-by: Otto Sabart
>
> Probably this should be combined into patch #2.
Yes, this makes sense.
I have just sent you v2 of this series of patches where I combined
patches #2 and #3.
Thank you for your review!
Ota
signature.asc
Description: PGP signature
[PATCH v2 4/4] doc: networking: add offload documents into main index file
This patch just adds references to offload documents into main table of contents in network documentation. Signed-off-by: Otto Sabart --- Documentation/networking/index.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 6a47629ef8ed..7034214cf87e 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -32,6 +32,8 @@ Contents: alias bridge snmp_counter + checksum-offloads + segmentation-offloads .. only:: subproject -- 2.17.2 signature.asc Description: PGP signature
[PATCH v2 2/4] doc: networking: convert offload files into RST and update references
This patch renames offload files. This is necessary for Sphinx.
Also update reference to checksum-offloads.rst file.
Whole kernel code was grepped for references using:
$ grep -r "\(segmentation\|checksum\)-offloads.txt" .
There should be no other references
to {segmentation,checksum}-offloads.txt files.
Signed-off-by: Otto Sabart
---
.../networking/{checksum-offloads.txt => checksum-offloads.rst} | 0
.../{segmentation-offloads.txt => segmentation-offloads.rst}| 0
include/linux/skbuff.h | 2 +-
3 files changed, 1 insertion(+), 1 deletion(-)
rename Documentation/networking/{checksum-offloads.txt =>
checksum-offloads.rst} (100%)
rename Documentation/networking/{segmentation-offloads.txt =>
segmentation-offloads.rst} (100%)
diff --git a/Documentation/networking/checksum-offloads.txt
b/Documentation/networking/checksum-offloads.rst
similarity index 100%
rename from Documentation/networking/checksum-offloads.txt
rename to Documentation/networking/checksum-offloads.rst
diff --git a/Documentation/networking/segmentation-offloads.txt
b/Documentation/networking/segmentation-offloads.rst
similarity index 100%
rename from Documentation/networking/segmentation-offloads.txt
rename to Documentation/networking/segmentation-offloads.rst
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 93f56fddd92a..4e671b46e767 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4296,7 +4296,7 @@ static inline bool skb_head_is_locked(const struct
sk_buff *skb)
/* Local Checksum Offload.
* Compute outer checksum based on the assumption that the
* inner checksum will be offloaded later.
- * See Documentation/networking/checksum-offloads.txt for
+ * See Documentation/networking/checksum-offloads.rst for
* explanation of how this works.
* Fill in outer checksum adjustment (e.g. with sum of outer
* pseudo-header) before calling.
--
2.17.2
signature.asc
Description: PGP signature
[PATCH v2 3/4] doc: networking: shorten the main title in offloads documents
The titles do not look very nice in the table of contents generated by Sphinx. I also think it is obvious that the documents are describing offloads in the Linux Networking Stack. Signed-off-by: Otto Sabart --- Documentation/networking/checksum-offloads.rst | 6 +++--- Documentation/networking/segmentation-offloads.rst | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/networking/checksum-offloads.rst b/Documentation/networking/checksum-offloads.rst index 1a1cd94a3f6d..905c8a84b103 100644 --- a/Documentation/networking/checksum-offloads.rst +++ b/Documentation/networking/checksum-offloads.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -=== -Checksum Offloads in the Linux Networking Stack -=== += +Checksum Offloads += Introduction diff --git a/Documentation/networking/segmentation-offloads.rst b/Documentation/networking/segmentation-offloads.rst index 1794bfe98196..89d1ee933e9f 100644 --- a/Documentation/networking/segmentation-offloads.rst +++ b/Documentation/networking/segmentation-offloads.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -=== -Segmentation Offloads in the Linux Networking Stack -=== += +Segmentation Offloads += Introduction -- 2.17.2 signature.asc Description: PGP signature
[PATCH v2 1/4] doc: networking: prepare offload documents for conversion into RST
Add small number of markups which are sufficient for conversion into reStructuredText. Unfortunately there was necessary to restructure all sections in checksum-offloads.txt file and create paragraphs separated by newline. There also must not be a space at the beginning of paragpraph. There are no semantic changes. Signed-off-by: Otto Sabart --- .../networking/checksum-offloads.txt | 179 ++ .../networking/segmentation-offloads.txt | 46 +++-- 2 files changed, 130 insertions(+), 95 deletions(-) diff --git a/Documentation/networking/checksum-offloads.txt b/Documentation/networking/checksum-offloads.txt index 27bc09cfcf6d..1a1cd94a3f6d 100644 --- a/Documentation/networking/checksum-offloads.txt +++ b/Documentation/networking/checksum-offloads.txt @@ -1,122 +1,143 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== Checksum Offloads in the Linux Networking Stack +=== Introduction -This document describes a set of techniques in the Linux networking stack - to take advantage of checksum offload capabilities of various NICs. +This document describes a set of techniques in the Linux networking stack to +take advantage of checksum offload capabilities of various NICs. The following technologies are described: - * TX Checksum Offload - * LCO: Local Checksum Offload - * RCO: Remote Checksum Offload + +* TX Checksum Offload +* LCO: Local Checksum Offload +* RCO: Remote Checksum Offload Things that should be documented here but aren't yet: - * RX Checksum Offload - * CHECKSUM_UNNECESSARY conversion + +* RX Checksum Offload +* CHECKSUM_UNNECESSARY conversion TX Checksum Offload === -The interface for offloading a transmit checksum to a device is explained - in detail in comments near the top of include/linux/skbuff.h. +The interface for offloading a transmit checksum to a device is explained in +detail in comments near the top of include/linux/skbuff.h. + In brief, it allows to request the device fill in a single ones-complement - checksum defined by the sk_buff fields skb->csum_start and - skb->csum_offset. The device should compute the 16-bit ones-complement - checksum (i.e. the 'IP-style' checksum) from csum_start to the end of the - packet, and fill in the result at (csum_start + csum_offset). -Because csum_offset cannot be negative, this ensures that the previous - value of the checksum field is included in the checksum computation, thus - it can be used to supply any needed corrections to the checksum (such as - the sum of the pseudo-header for UDP or TCP). +checksum defined by the sk_buff fields skb->csum_start and skb->csum_offset. +The device should compute the 16-bit ones-complement checksum (i.e. the +'IP-style' checksum) from csum_start to the end of the packet, and fill in the +result at (csum_start + csum_offset). + +Because csum_offset cannot be negative, this ensures that the previous value of +the checksum field is included in the checksum computation, thus it can be used +to supply any needed corrections to the checksum (such as the sum of the +pseudo-header for UDP or TCP). + This interface only allows a single checksum to be offloaded. Where - encapsulation is used, the packet may have multiple checksum fields in - different header layers, and the rest will have to be handled by another - mechanism such as LCO or RCO. +encapsulation is used, the packet may have multiple checksum fields in +different header layers, and the rest will have to be handled by another +mechanism such as LCO or RCO. + CRC32c can also be offloaded using this interface, by means of filling - skb->csum_start and skb->csum_offset as described above, and setting - skb->csum_not_inet: see skbuff.h comment (section 'D') for more details. +skb->csum_start and skb->csum_offset as described above, and setting +skb->csum_not_inet: see skbuff.h comment (section 'D') for more details. + No offloading of the IP header checksum is performed; it is always done in - software. This is OK because when we build the IP header, we obviously - have it in cache, so summing it isn't expensive. It's also rather short. +software. This is OK because when we build the IP header, we obviously have it +in cache, so summing it isn't expensive. It's also rather short. + The requirements for GSO are more complicated, because when segmenting an - encapsulated packet both the inner and outer checksums may need to be - edited or recomputed for each resulting segment. See the skbuff.h comment - (section 'E') for more details. +encapsulated packet both the inner and outer checksums may need to be edited or +recomputed for each resulting segment. See the skbuff.h comment (section 'E') +for more details. A driver declares its offload capabilities in netdev->hw_features; see - Documentation/networking/netdev-features.txt for more. Note that a device - which only advertises
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 5, 2019 at 3:16 PM Linus Torvalds wrote: > > It goes back to forever, it looks like. I can't find a reason. Our man-pages talk abouit the "without doing IO" part. That may be the result of our code, though, not the reason for it. The BSD man-page has other flags, but doesn't describe what "in core" really means: MINCORE_INCOREPage is in core (resident). MINCORE_REFERENCEDPage has been referenced by us. MINCORE_MODIFIEDPage has been modified by us. MINCORE_REFERENCED_OTHER Page has been referenced. MINCORE_MODIFIED_OTHERPage has been modified. MINCORE_SUPERPage is part of a large (``super'') page. but the fact that it has MINCORE_MODIFIED_OTHER does obviously imply that yes, historically it really did look up the pages elsewhere, not just in the page tables. Still, maybe we can get away with just making it be about our own page tables. That would be lovely. Linus
[PATCH v2 0/4] doc: network: integrate offload documents into doc tree
Changes in v2:
- Patch #3 and #2 were combined into patch #2.
---
This series of patches integrates checksum-offloads and
segmentation-offloads documents into documentation tree.
These patches do not change semantics of these documents. There are only
changes which are needed for successful integration into documentation
tree generated by Sphinx.
Otto Sabart (4):
doc: networking: prepare offload documents for conversion into RST
doc: networking: convert offload files into RST and update references
doc: networking: shorten the main title in offloads documents
doc: networking: add offload documents into main index file
.../networking/checksum-offloads.rst | 143 ++
.../networking/checksum-offloads.txt | 122 ---
Documentation/networking/index.rst| 2 +
...offloads.txt => segmentation-offloads.rst} | 48 +++---
include/linux/skbuff.h| 2 +-
5 files changed, 177 insertions(+), 140 deletions(-)
create mode 100644 Documentation/networking/checksum-offloads.rst
delete mode 100644 Documentation/networking/checksum-offloads.txt
rename Documentation/networking/{segmentation-offloads.txt =>
segmentation-offloads.rst} (88%)
--
2.17.2
signature.asc
Description: PGP signature
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 5, 2019 at 3:05 PM Linus Torvalds
wrote:
>
> That would be nicer than my patch, simply because removing code is
> always nice. And arguably it's a better semantic anyway.
Yeah, I wonder why we did that thing where mincore() walks the page
tables, but if they are empty it looks in the page cache.
[... goes and looks in history ..]
It goes back to forever, it looks like. I can't find a reason.
Anyway, a removal patch would look something like the attached, I
think. That makes mincore() actually say how many pages are in _this_
mapping, not how many pages could be paged in without doing IO.
Hmm. Maybe we should try this first. Simplicity is always good.
Again, obviously untested.
Linus
mm/mincore.c | 74 +---
1 file changed, 6 insertions(+), 68 deletions(-)
diff --git a/mm/mincore.c b/mm/mincore.c
index 218099b5ed31..317eb64ea4ef 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -42,64 +42,12 @@ static int mincore_hugetlb(pte_t *pte, unsigned long hmask, unsigned long addr,
return 0;
}
-/*
- * Later we can get more picky about what "in core" means precisely.
- * For now, simply check to see if the page is in the page cache,
- * and is up to date; i.e. that no page-in operation would be required
- * at this time if an application were to map and access this page.
- */
-static unsigned char mincore_page(struct address_space *mapping, pgoff_t pgoff)
-{
- unsigned char present = 0;
- struct page *page;
-
- /*
- * When tmpfs swaps out a page from a file, any process mapping that
- * file will not get a swp_entry_t in its pte, but rather it is like
- * any other file mapping (ie. marked !present and faulted in with
- * tmpfs's .fault). So swapped out tmpfs mappings are tested here.
- */
-#ifdef CONFIG_SWAP
- if (shmem_mapping(mapping)) {
- page = find_get_entry(mapping, pgoff);
- /*
- * shmem/tmpfs may return swap: account for swapcache
- * page too.
- */
- if (xa_is_value(page)) {
- swp_entry_t swp = radix_to_swp_entry(page);
- page = find_get_page(swap_address_space(swp),
- swp_offset(swp));
- }
- } else
- page = find_get_page(mapping, pgoff);
-#else
- page = find_get_page(mapping, pgoff);
-#endif
- if (page) {
- present = PageUptodate(page);
- put_page(page);
- }
-
- return present;
-}
-
static int __mincore_unmapped_range(unsigned long addr, unsigned long end,
struct vm_area_struct *vma, unsigned char *vec)
{
unsigned long nr = (end - addr) >> PAGE_SHIFT;
- int i;
- if (vma->vm_file) {
- pgoff_t pgoff;
-
- pgoff = linear_page_index(vma, addr);
- for (i = 0; i < nr; i++, pgoff++)
- vec[i] = mincore_page(vma->vm_file->f_mapping, pgoff);
- } else {
- for (i = 0; i < nr; i++)
- vec[i] = 0;
- }
+ memset(vec, 0, nr);
return nr;
}
@@ -144,21 +92,11 @@ static int mincore_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
else { /* pte is a swap entry */
swp_entry_t entry = pte_to_swp_entry(pte);
- if (non_swap_entry(entry)) {
-/*
- * migration or hwpoison entries are always
- * uptodate
- */
-*vec = 1;
- } else {
-#ifdef CONFIG_SWAP
-*vec = mincore_page(swap_address_space(entry),
- swp_offset(entry));
-#else
-WARN_ON(1);
-*vec = 1;
-#endif
- }
+ /*
+ * migration or hwpoison entries are always
+ * uptodate
+ */
+ *vec = !!non_swap_entry(entry);
}
vec++;
}
Re: [PATCH 1/2] Input: rotary_encoder - Support key events
On Sat, Jan 5, 2019 at 2:27 PM Donghoon Han wrote:
>
> From: Steven Han
>
> Support generating EV_KEY pair, instead of EV_REL.
>
> Signed-off-by: Donghoon Han
> ---
> drivers/input/misc/rotary_encoder.c | 23 +--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/rotary_encoder.c
> b/drivers/input/misc/rotary_encoder.c
> index 72eee6d55527..180e35884289 100644
> --- a/drivers/input/misc/rotary_encoder.c
> +++ b/drivers/input/misc/rotary_encoder.c
> @@ -41,6 +41,8 @@ struct rotary_encoder {
> u32 steps;
> u32 axis;
> bool relative_axis;
> + bool relative_keys;
> + u32 keycodes[2];
> bool rollover;
> enum rotary_encoder_encoding encoding;
>
> @@ -79,6 +81,10 @@ static void rotary_encoder_report_event(struct
> rotary_encoder *encoder)
> if (encoder->relative_axis) {
> input_report_rel(encoder->input,
> encoder->axis, encoder->dir);
> + } else if (encoder->relative_keys) {
> + u32 keycode = encoder->keycodes[encoder->dir > 0];
> + input_event(encoder->input, EV_KEY, keycode, 1);
You need input_sync() here.
> + input_event(encoder->input, EV_KEY, keycode, 0);
> } else {
> unsigned int pos = encoder->pos;
>
> @@ -237,6 +243,16 @@ static int rotary_encoder_probe(struct platform_device
> *pdev)
> device_property_read_u32(dev, "linux,axis", >axis);
> encoder->relative_axis =
> device_property_read_bool(dev,
> "rotary-encoder,relative-axis");
> + encoder->relative_keys =
> + device_property_read_bool(dev,
> "rotary-encoder,relative-keys");
> + if (encoder->relative_keys) {
> + err = device_property_read_u32_array(dev,
> + "rotary-encoder,relative-keycodes",
> + encoder->keycodes, 2);
> + if (err)
> + dev_err(dev, "unable to get keycodes: %d\n", err);
> + return err;
> + }
>
> encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
> if (IS_ERR(encoder->gpios)) {
> @@ -260,9 +276,12 @@ static int rotary_encoder_probe(struct platform_device
> *pdev)
> input->id.bustype = BUS_HOST;
> input->dev.parent = dev;
>
> - if (encoder->relative_axis)
> + if (encoder->relative_axis) {
> input_set_capability(input, EV_REL, encoder->axis);
> - else
> + } else if (encoder->relative_keys) {
> + input_set_capability(input, EV_KEY, encoder->keycodes[0]);
> + input_set_capability(input, EV_KEY, encoder->keycodes[1]);
> + } else
> input_set_abs_params(input,
> encoder->axis, 0, encoder->steps, 0, 1);
>
> --
> 2.17.1
>
Thanks.
--
Dmitry
Re: [PATCH 2/2] Input: rotaty-encoder - Add DT binding document
On Sat, Jan 5, 2019 at 2:27 PM Donghoon Han wrote:
>
> Add DT binding document for rotary-encoder, keycode options.
>
> Signed-off-by: Donghoon Han
> ---
> .../devicetree/bindings/input/rotary-encoder.txt | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> index f99fe5cdeaec..113640079de3 100644
> --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> @@ -12,6 +12,10 @@ Optional properties:
> - rotary-encoder,relative-axis: register a relative axis rather than an
>absolute one. Relative axis will only generate +1/-1 events on the input
>device, hence no steps need to be passed.
> +- rotary-encoder,relative-keys : generate pair of key events. This setting
> + behaves just like relative-axis, generating key events. keycode[2]
> + corresponds -1/1 events.
> +- rotary-encoder,relative-keycodes : keycodes for relative-keys
> - rotary-encoder,rollover: Automatic rollover when the rotary value becomes
>greater than the specified steps or smaller than 0. For absolute axis only.
> - rotary-encoder,steps-per-period: Number of steps (stable states) per
> period.
> @@ -48,3 +52,11 @@ Example:
> rotary-encoder,encoding = "binary";
> rotary-encoder,rollover;
> };
> +
> + rotary@2 {
> + compatible = "rotary-encoder";
> + gpios = < 21 0>, < 22 0>;
> + rotary-encoder,relative-keys;
> + rotary-encoder,relative-keycode = <103>, <108>;
> + rotary-encoder,steps-per-period = <2>;
Do you need steps for keys? They weren't required for the relative axis mode.
Thanks.
--
Dmitry
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, 5 Jan 2019, Jann Horn wrote: > > Provide vm.mincore_privileged sysctl, which makes it possible to mincore() > > start returning -EPERM in case it's invoked by a process lacking > > CAP_SYS_ADMIN. > > > > The default behavior stays "mincore() can be used by anybody" in order to > > be conservative with respect to userspace behavior. > > > > [1] https://www.theregister.co.uk/2019/01/05/boffins_beat_page_cache/ > > Just checking: I guess /proc/$pid/pagemap (iow, the pagemap_read() > handler) is less problematic because it only returns data about the > state of page tables, and doesn't query the address_space? In other > words, it permits monitoring evictions, but non-intrusively detecting > that something has been loaded into memory by another process is > harder? So I was just about to immediately reply that we don't expose pagemap anymore due to rowhammer, but apparently that's not true any more (this behavioud was originally introduced by ab676b7d6fbf, but then changed via 1c90308e7a77 (and further adjusted for swap entries in ab6ecf247a, but I guess that's not all that interesting). Hmm. But unless it has been mapped with MAP_POPULATE (whcih is outside the attacker's control), there is no guarantee that the mappings would actually be there, right? -- Jiri Kosina SUSE Labs
Re: [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
On Sun, 30 Dec 2018, I wrote:
> On Sat, 29 Dec 2018, LEROY Christophe wrote:
>
> > Finn Thain a ?crit?:
> >
> > > Make use of arch_nvram_ops in device drivers so that the nvram_* function
> > > exports can be removed.
> > >
> > > Since they are no longer global symbols, rename the PPC32 nvram_*
> > > functions
> > > appropriately.
> > >
> > > Signed-off-by: Finn Thain
> > > ---
> > > arch/powerpc/kernel/setup_32.c | 8
> > > drivers/char/generic_nvram.c | 4 ++--
> > > drivers/video/fbdev/controlfb.c| 4 ++--
> > > drivers/video/fbdev/imsttfb.c | 4 ++--
> > > drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
> > > drivers/video/fbdev/platinumfb.c | 4 ++--
> > > drivers/video/fbdev/valkyriefb.c | 4 ++--
> > > 7 files changed, 15 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kernel/setup_32.c
> > > b/arch/powerpc/kernel/setup_32.c
> > > index e0d045677472..bdbe6acbef11 100644
> > > --- a/arch/powerpc/kernel/setup_32.c
> > > +++ b/arch/powerpc/kernel/setup_32.c
> > > @@ -152,20 +152,18 @@ __setup("l3cr=", ppc_setup_l3cr);
> > >
> > > #ifdef CONFIG_GENERIC_NVRAM
> > >
> > > -unsigned char nvram_read_byte(int addr)
> > > +static unsigned char ppc_nvram_read_byte(int addr)
> > > {
> > > if (ppc_md.nvram_read_val)
> > > return ppc_md.nvram_read_val(addr);
> > > return 0xff;
> > > }
> > > -EXPORT_SYMBOL(nvram_read_byte);
> > >
> > > -void nvram_write_byte(unsigned char val, int addr)
> > > +static void ppc_nvram_write_byte(unsigned char val, int addr)
> > > {
> > > if (ppc_md.nvram_write_val)
> > > ppc_md.nvram_write_val(addr, val);
> > > }
> > > -EXPORT_SYMBOL(nvram_write_byte);
> > >
> > > static ssize_t ppc_nvram_get_size(void)
> > > {
> > > @@ -182,6 +180,8 @@ static long ppc_nvram_sync(void)
> > > }
> > >
> > > const struct nvram_ops arch_nvram_ops = {
> > > + .read_byte = ppc_nvram_read_byte,
> > > + .write_byte = ppc_nvram_write_byte,
> > > .get_size = ppc_nvram_get_size,
> > > .sync = ppc_nvram_sync,
> > > };
> > > diff --git a/drivers/char/generic_nvram.c b/drivers/char/generic_nvram.c
> > > index f32d5663de95..41b76bf9614e 100644
> > > --- a/drivers/char/generic_nvram.c
> > > +++ b/drivers/char/generic_nvram.c
> > > @@ -48,7 +48,7 @@ static ssize_t read_nvram(struct file *file, char __user
> > > *buf,
> > > if (*ppos >= nvram_len)
> > > return 0;
> > > for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
> > > - if (__put_user(nvram_read_byte(i), p))
> > > + if (__put_user(arch_nvram_ops.read_byte(i), p))
> >
> > Instead of modifying all drivers (in this patch and previous ones related to
> > other arches), wouldn't it be better to add helpers like the following in
> > nvram.h:
> >
> > Static inline unsigned char nvram_read_byte(int addr)
> > {
> >return arch_nvram_ops.read_byte(addr);
> > }
> >
>
> Is there some benefit, or is that just personal taste?
>
> Avoiding changes to call sites avoids code review, but I think 1) the
> thinkpad_acpi changes have already been reviewed and 2) the fbdev changes
> need review anyway.
>
> Your suggesion would add several new entities and one extra layer of
> indirection.
>
Contrary to what I said above, this kind of double indirection could be
useful if it allows us to avoid the kind of double indirection which Arnd
objected to (which arises when an arch_nvram_ops method invokes a ppc_md
method). For example,
static inline unsigned char nvram_read_byte(int addr)
{
#ifdef CONFIG_PPC
return ppc_md.nvram_read_byte(addr);
#else
return arch_nvram_ops.read_byte(addr);
#endif
}
I'll try this approach for v9 if there are no objections. It may be the
least invasive approach. Also, arch_nvram_ops can remain const.
--
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 5, 2019 at 2:55 PM Jann Horn wrote: > > Just checking: I guess /proc/$pid/pagemap (iow, the pagemap_read() > handler) is less problematic because it only returns data about the > state of page tables, and doesn't query the address_space? In other > words, it permits monitoring evictions, but non-intrusively detecting > that something has been loaded into memory by another process is > harder? Yes. I think it was brought up during the original report, but to use the pagemap for this, you'd basically need to first populate all the pages, and then wait for pageout. So pagemap *does* leak very similar data, but it's much harder to use as an attack vector. That said, I think "mincore()" is just the simple one. You *can* (and this was also discussed on the security list) do things like - fault in a single page - the kernel will opportunistically fault in pages that it already has available _around_ that page. - then use pagemap (or just _timing_ - no real kernel support needed) to see if those pages are now mapped in your address space so honestly, mincore is just the "big hammer" and easy way to get at some of this data. But it's probably worth closing exactly because it's easy. There are other ways to get at the "are these pages mapped" information, but they are a lot more combersome to use. Side note: maybe we could just remove the "__mincore_unmapped_range()" thing entirely, and basically make mincore() do what pagemap does, which is to say "are the pages mapped in this VM". That would be nicer than my patch, simply because removing code is always nice. And arguably it's a better semantic anyway. Linus
Re: [PATCH] Input: goodix - decouple irq and reset lines
Hi Alex, On Fri, Jan 04, 2019 at 05:00:48PM +0100, Alex Gonzalez wrote: > The Goodix touch controller allows the use of two optional GPIOs (RESET > and INT) to reset the touch controller, select the I2C address of the > device and exit the device from sleep mode. > > The current implementation requires both GPIOs to be provided, however, > it is possible to provide only the INT line and not to have the RESET line > available but pulled-up. > > Designs that only provide the INT line are able to operate the touch on > the default I2C address but will not be able to reset the touch via > software or place the device in sleep mode. I do not have a datasheet for the device, so I am not sure if reset line is actually needed to put the device into sleep mode. As far as I can see from the code we suspend it by pulsing INT line and then sending a command to the controller, and resuming by pulsing the INT line again. So it sounds to me INT only designs _could_ place device in sleep mode. As far as the patch goes, if you do not need to execute reset or put device into low power mode, you do not need to specify any of the GPIOs as GPIO resources. Simply specify the INT GPIO as your interrupt source (GpioInt() in ACPI world or "interrupts = < NNN IRQF_TRIGGER_WHATEVER>" in DT world and be done with it. Thanks. -- Dmitry
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 5, 2019 at 6:27 PM Jiri Kosina wrote: > There are possibilities [1] how mincore() could be used as a converyor of > a sidechannel information about pagecache metadata. > > Provide vm.mincore_privileged sysctl, which makes it possible to mincore() > start returning -EPERM in case it's invoked by a process lacking > CAP_SYS_ADMIN. > > The default behavior stays "mincore() can be used by anybody" in order to > be conservative with respect to userspace behavior. > > [1] https://www.theregister.co.uk/2019/01/05/boffins_beat_page_cache/ Just checking: I guess /proc/$pid/pagemap (iow, the pagemap_read() handler) is less problematic because it only returns data about the state of page tables, and doesn't query the address_space? In other words, it permits monitoring evictions, but non-intrusively detecting that something has been loaded into memory by another process is harder?
Re: [PATCH] PCI: Add no-D3 quirk for Mellanox ConnectX-[45]
On Sat, 2019-01-05 at 10:51 -0700, Jason Gunthorpe wrote: > > > Interesting. I've investigated this further, though I don't have as > > many new clues as I'd like. The problem occurs reliably, at least on > > one particular type of machine (a POWER8 "Garrison" with ConnectX-4). > > I don't yet know if it occurs with other machines, I'm having trouble > > getting access to other machines with a suitable card. I didn't > > manage to reproduce it on a different POWER8 machine with a > > ConnectX-5, but I don't know if it's the difference in machine or > > difference in card revision that's important. > > Make sure the card has the latest firmware is always good advice.. > > > So possibilities that occur to me: > > * It's something specific about how the vfio-pci driver uses D3 > > state - have you tried rebinding your device to vfio-pci? > > * It's something specific about POWER, either the kernel or the PCI > > bridge hardware > > * It's something specific about this particular type of machine > > Does the EEH indicate what happend to actually trigger it? In a very cryptic way that requires manual parsing using non-public docs sadly but yes. From the look of it, it's a completion timeout. Looks to me like we don't get a response to a config space access during the change of D state. I don't know if it's the write of the D3 state itself or the read back though (it's probably detected on the read back or a subsequent read, but that doesn't tell me which specific one failed). Some extra logging in OPAL might help pin that down by checking the InA error state in the config accessor after the config write (and polling on it for a while as from a CPU perspective I don't knw if the write is synchronous, probably not). Cheers, Ben.
Re: [PATCH net 1/4] umh: add exit routine for UMH process
From: Taehee Yoo
Date: Mon, 31 Dec 2018 01:31:43 +0900
> +void exit_umh(struct task_struct *tsk)
> +{
> + struct umh_info *info;
> + pid_t pid = tsk->pid;
> +
> + mutex_lock(_list_lock);
> + list_for_each_entry(info, _list, list) {
So this is probably too expensive of a cost for every process exit.
The problem is that the cost will be taken even if the process is
not a UMH.
I've taken my time to respond in hopes that I could come up with a
good alternative to suggest, but so far I don't have any better ideas.
I'll keep thinking about this some more, please let me know if you
have any ideas.
Re: [GIT PULL] xfs: more updates for v4.21
The pull request you sent on Thu, 3 Jan 2019 17:06:44 -0800: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-4.21-merge-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/acda9efa8c62d4baa0395c83bda43f252137e302 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Ceph updates for 4.21-rc1
The pull request you sent on Thu, 3 Jan 2019 16:39:26 +0100: > https://github.com/ceph/ceph-client.git tags/ceph-for-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c7eaf342ecb164d79275a6c1c93aef19293a4aaf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] iomap: more updates for v4.21
The pull request you sent on Thu, 3 Jan 2019 17:06:45 -0800: > git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/iomap-4.21-merge-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3cd6d495db2a0acfd2854f43aac8bfc5914bc89c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL][PATCH] sh: ftrace: Fix missing parenthesis in WARN_ON()
The pull request you sent on Thu, 3 Jan 2019 22:18:57 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > trace-v4.21-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a67012412e5a820c44239af9712a1a6037b33fd4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
Hi! > >Grab yourself an RGB LED and play with it; you'll see what the > >problems are. It is hard to explain colors over email... > > Video [0] gives some overview of lp5024 capabilities. > > I don't see any problems in exposing separate red,green,blue > files and brightness for the devices with hardware support for > that. Well, that's what we do today, as three separate LEDs, right? I don't have problem with that, either; other drivers already do that. He's free to use existing same interface. But that is insufficient, as it does not allow simple stuff, such as turning led "white". So... perhaps we should agree on requirements, first, and then we can discuss solutions? Requirements for RGB LED interface: 1) Userspace should be able to set the white color 2) Userspace should be able to arbitrary color from well known list and it should approximately match what would CRT, LCD or OLED monitor display 2a) LEDs probably slightly change color as they age. That's out of scope, unless the variation is much greater than on monitors. 2b) Manufacturing differences cause small color variation. Again, that's out of scope, unless the variation is much greater than on monitors. Nice to have features: 3) Full range of available colors/intensities should be available to userspace 4) Interface should work well with existing triggers 5) It would be nice if userland knew how many lumens are produced at each wavelength for each setting (again, minus aging and manufacturing variations). 6) Complexity of math in kernel should be low, and preferably it should be integer or fixed point Problems: a) RGB LEDs are usually not balanced. Setting 100% PWM on red/green/blue channels will result in nothing close to white light. In fact, to get white light on N900, blue and green channel's PWM needs to be set pretty low, as in 5%. b) LED class does not define any relation between "brightness" in sysfs and ammount of light in lumens. Some drivers use close to linear relation, some use exponential relation. Human eyes percieve logarithm of lumens. RGB color model uses even more complex function. c) Except for white LEDs, LEDs are basically sources of single wavelength of light, while CRTs and LCDs produce broader spectrums. d) RG, RGBW and probably other LED combinations exist. e) Not all "red" LEDs will produce same wavelength. Similar differences will exist for other colors. f) We have existing RGB LEDs represented as three separate monochromatic LEDs in sysfs. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 3/5] doc: networking: update references to files describing offloads
From: Otto Sabart
Date: Fri, 4 Jan 2019 11:42:29 +0100
> Update reference to checksum-offloads.rst file which was converted into
> RST.
>
> Whole kernel code was grepped for references using:
> $ grep -r "\(segmentation\|checksum\)-offloads.txt" .
>
> There should be no other references
> to {segmentation,checksum}-offloads.txt files.
>
> Signed-off-by: Otto Sabart
Probably this should be combined into patch #2.
Re: [PATCH] Staging: iio: adt7316: Add regmap support
On Sat, Jan 05, 2019 at 05:20:37PM +, Jonathan Cameron wrote:
> +CC Jeremy who is also working with this device.
>
> On Sun, 23 Dec 2018 19:32:24 +0530
> Shreeya Patel wrote:
>
> > Both i2c and spi drivers have functions for reading and writing
> > to/from registers. Remove this redundant and common code by using
> > regmap API.
> > Also remove multi_read and multi_write functions from i2c
> > and spi driver as they are not being used anywhere.
> >
> > Signed-off-by: Shreeya Patel
>
> I would have preferred an initial patch that removed the multi_read
> and multi_write first as that would (I assume) be easily separated
> from the 'major' change of moving to regmap. I also suggest
> another section to pull out to a precursor patch below.
>
> The result looks fine to me.
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/staging/iio/addac/adt7316-i2c.c | 101 ++--
> > drivers/staging/iio/addac/adt7316-spi.c | 94 +++
> > drivers/staging/iio/addac/adt7316.c | 147
> > drivers/staging/iio/addac/adt7316.h | 15 +--
> > 4 files changed, 103 insertions(+), 254 deletions(-)
> >
> > diff --git a/drivers/staging/iio/addac/adt7316-i2c.c
> > b/drivers/staging/iio/addac/adt7316-i2c.c
> > index ac91163656b5..435b65845174 100644
> > --- a/drivers/staging/iio/addac/adt7316-i2c.c
> > +++ b/drivers/staging/iio/addac/adt7316-i2c.c
> > @@ -12,105 +12,28 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "adt7316.h"
> >
> > -/*
> > - * adt7316 register access by I2C
> > - */
> > -static int adt7316_i2c_read(void *client, u8 reg, u8 *data)
> > -{
> > - struct i2c_client *cl = client;
> > - int ret;
> > -
> > - ret = i2c_smbus_write_byte(cl, reg);
> > - if (ret < 0) {
> > - dev_err(>dev, "I2C fail to select reg\n");
> > - return ret;
> > - }
> > -
> > - ret = i2c_smbus_read_byte(client);
> > -
> > - if (!ret)
> > - return -EIO;
> > -
> > - if (ret < 0) {
> > - dev_err(>dev, "I2C read error\n");
> > - return ret;
> > - }
> > -
> > - *data = ret;
> > -
> > - return 0;
> > -}
> > -
> > -static int adt7316_i2c_write(void *client, u8 reg, u8 data)
> > -{
> > - struct i2c_client *cl = client;
> > - int ret = 0;
> > -
> > - ret = i2c_smbus_write_byte_data(cl, reg, data);
> > - if (ret < 0)
> > - dev_err(>dev, "I2C write error\n");
> > -
> > - return ret;
> > -}
> > -
> > -static int adt7316_i2c_multi_read(void *client, u8 reg, u8 count, u8 *data)
> > -{
> > - struct i2c_client *cl = client;
> > - int i, ret = 0;
> > -
> > - if (count > ADT7316_REG_MAX_ADDR)
> > - count = ADT7316_REG_MAX_ADDR;
> > -
> > - for (i = 0; i < count; i++) {
> > - ret = adt7316_i2c_read(cl, reg, [i]);
> > - if (ret < 0) {
> > - dev_err(>dev, "I2C multi read error\n");
> > - return ret;
> > - }
> > - }
> > -
> > - return 0;
> > -}
> > -
> > -static int adt7316_i2c_multi_write(void *client, u8 reg, u8 count, u8
> > *data)
> > -{
> > - struct i2c_client *cl = client;
> > - int i, ret = 0;
> > -
> > - if (count > ADT7316_REG_MAX_ADDR)
> > - count = ADT7316_REG_MAX_ADDR;
> > -
> > - for (i = 0; i < count; i++) {
> > - ret = adt7316_i2c_write(cl, reg, data[i]);
> > - if (ret < 0) {
> > - dev_err(>dev, "I2C multi write error\n");
> > - return ret;
> > - }
> > - }
> > -
> > - return 0;
> > -}
> > -
> > /*
> > * device probe and remove
> > */
> > -
> > static int adt7316_i2c_probe(struct i2c_client *client,
> > const struct i2c_device_id *id)
> > {
> > - struct adt7316_bus bus = {
> > - .client = client,
> > - .irq = client->irq,
> > - .read = adt7316_i2c_read,
> > - .write = adt7316_i2c_write,
> > - .multi_read = adt7316_i2c_multi_read,
> > - .multi_write = adt7316_i2c_multi_write,
> > - };
> > + struct regmap *regmap;
> > +
> > + regmap = devm_regmap_init_i2c(client, _regmap_config);
> > +
> > + if (IS_ERR(regmap)) {
> > + dev_err(>dev, "Error initializing i2c regmap: %ld\n",
> > + PTR_ERR(regmap));
> > + return PTR_ERR(regmap);
> > + }
> >
> > - return adt7316_probe(>dev, , id->name);
> > + return adt7316_probe(>dev, regmap, id ? id->name : NULL,
> > +client->irq);
> > }
> >
> > static const struct i2c_device_id adt7316_i2c_id[] = {
> > diff --git a/drivers/staging/iio/addac/adt7316-spi.c
> > b/drivers/staging/iio/addac/adt7316-spi.c
> > index e75827e326a6..9e3decb5cb77 100644
> > --- a/drivers/staging/iio/addac/adt7316-spi.c
> > +++ b/drivers/staging/iio/addac/adt7316-spi.c
> > @@ -11,79 +11,12 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "adt7316.h"
> >
> > #define
Re: [PATCH V2] usbcore: Select only first configuration for non-UAC3 compliant devices
Hi Saranya
On Sun, 6 Jan 2019 at 04:41, wrote:
>
> From: Saranya Gopal
>
> In most of the UAC1 and UAC2 audio devices, the first
> configuration is most often the best configuration.
> However, with recent patch to support UAC3 configuration,
> second configuration was unintentionally chosen for
> some of the UAC1/2 devices that had more than one
> configuration. This was because of the existing check
> after the audio config check which selected any config
> which had a non-vendor class. This patch fixes this issue.
>
> Fixes: f13912d3f014 ("usbcore: Select UAC3 configuration for audio if
> present")
> Reported-by: Con Kolivas
> Signed-off-by: Saranya Gopal >
I can confirm the above patch fixes my problem.
Tested-by: Con Kolivas
Thanks!
Con
Re: [git pull] vfs.git mount.part1
The pull request you sent on Fri, 4 Jan 2019 19:26:48 +: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git mount.part1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/505b050fdf42097883b2d37b8e796e1f11dbef50 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, Jan 5, 2019 at 12:43 PM Jiri Kosina wrote: > > > Who actually _uses_ mincore()? That's probably the best guide to what > > we should do. Maybe they open the file read-only even if they are the > > owner, and we really should look at file ownership instead. > > Yeah, well > > https://codesearch.debian.net/search?q=mincore > > is a bit too much mess to get some idea quickly I am afraid. Yeah, heh. And the first hit is 'fincore', which probably nobody cares about anyway, but it does fd = open (name, O_RDONLY) .. mmap(window, len, PROT_NONE, MAP_PRIVATE, .. so if we want to keep that working, we'd really need to actually check file ownership rather than just looking at f_mode. But I don't know if anybody *uses* and cares about fincore, and it's particularly questionable for non-root users. And the Android go runtime code seems to oddly use mincore to figure out page size: // try using mincore to detect the physical page size. // mincore should return EINVAL when address is not a multiple of system page size. which is all kinds of odd, but whatever.. Why mincore, rather than something sane and obvious like mmap? Don't ask me... Anyway, the Debian code search just results in mostly non-present stuff. It's sad that google code search is no more. It was great for exactly these kinds of questions. The mono runtime seems to have some mono_pages_not_faulted() function, but I don't know if people use it for file mappings, and I couldn't find any interesting users of it. I didn't find anything that seems to really care, but I gave up after a few pages of really boring stuff. Linus
Re: [PATCH] lib/genalloc.c: include vmalloc.h
On Sat, Jan 5, 2019 at 1:35 PM Linus Torvalds wrote: > > On Sat, Jan 5, 2019 at 1:21 PM Olof Johansson wrote: > > > > Fixes build break on most ARM/ARM64 defconfigs: > > Interesting. > > Andrew, I thought ARM was one of the platforms that your tree compiled > against? Or was some other change just hiding this? > > Anyway, I'll apply as soon as the previous build test finishes. Looks like the patch might have been queued pretty recently, I don't see it in the Jan 3 linux-next tree. I'm not familiar with Andrew's patch queues, but it seems to be there in the 'mmots' (Jan 4), but not in 'mmotm' (Dec 22). -Olof -Olof
Re: [PATCH] lib/genalloc.c: include vmalloc.h
On Sat, Jan 5, 2019 at 1:21 PM Olof Johansson wrote: > > Fixes build break on most ARM/ARM64 defconfigs: Interesting. Andrew, I thought ARM was one of the platforms that your tree compiled against? Or was some other change just hiding this? Anyway, I'll apply as soon as the previous build test finishes. Linus
Re: [PATCH v2 0/4] rtlwifi: Fix issues with rtl8723ae
On 1/5/19 12:38 PM, Bernd Edlinger wrote: Currently the rtl8723ae driver is broken (since v4.7). Connection to AP is lost very often, especially when the signal level is not very good. The main issue is the power save mode is basically not working, and seems to trigger a firmware bug. So I had to take out the FW LPS mode handling. While debugging the driver I found a couple related issues, for instance that the signal level in dm.undec_sm_pwdb is no longer accurate (may be even much too high) when no more packets are received, and it increases the likelihood to receive something if the input gain is set to maximum. The patch was tested with the rtl8723ae PCI card in my laptop against a FRITZ!Box 7590 AP -- the WiFi connection works now very reliable for me. V2 of the patch adjusts the defaults of swlps and fwlps module parameters to match the firmware capabilities instead of removing the whole code, so it can be easily re-activated once a firmware update is available. Bernd Edlinger (4): rtlwifi: rtl8723ae: Take the FW LPS mode handling out rtlwifi: rtl8723ae: Don't use dm.undec_sm_pwdb for input gain control when no beacon was received in the connected state rtlwifi: rtl8723ae: Re-introduce rtl8723e_dm_refresh_rate_adaptive_mask rtlwifi: Move the clearing of rtlpriv->link_info.num_rx_inperiod in rtl_watchdog_wq_callback a few lines down The subject on all 4 of these need to be modified. Only the first line will be shown as the "subject", which will not make much sense. In addition, you need to include the changes in the cover letter, and in the actual patch after the --- line. In that section, you mention what changes were made in each revision, then follow with another --- line. That info is there for the maintainers - it will be stripped before the patch is merged. Larry
Re: [PATCH v9 14/27] pwm: jz4740: Improve algorithm of clock calculation
Hello Paul, On Sat, Jan 05, 2019 at 06:05:38PM -0300, Paul Cercueil wrote: > On Sat, Jan 5, 2019 at 4:57 PM, Uwe Kleine-König > wrote: > > You are assuming stuff here about the parent clk which isn't guaranteed > > (AFAICT) by the clk framework: If you call clk_round_rate(clk, rate - 1) > > this might well return rate even if the clock could run slower than > > rate. > > It may not be guaranteed by the clock framework itself, but it is guaranteed > to behave like that on this family of SoCs. You shouldn't rely on that. Experience shows that people will start copying code to machines where this is not guaranteed. Even if they don't copy and only learn from reading this is bad. Also how do you guarantee that this won't change in the future making the pwm code break without noticing? If you use an API better don't assume more things given than are guaranteed by the API. Having said that I would consider it sensible to introduce something like clk_roundup_rate() and clk_rounddown_rate() which would allow calculations like that. > > Wouldn't it make sense to start iterating with rate = 0x * 1e9 / > > period? Otherwise you get bad configurations if rate is considerable > > slower than necessary. > > The algorithm will start with 'rate' being the parent clock's rate, which > will always be the highest rate that the child clock will support. Ah right, I missed that bit. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH] lib/genalloc.c: include vmalloc.h
Fixes build break on most ARM/ARM64 defconfigs:
lib/genalloc.c: In function 'gen_pool_add_virt':
lib/genalloc.c:190:10: error: implicit declaration of function 'vzalloc_node';
did you mean 'kzalloc_node'?
lib/genalloc.c:190:8: warning: assignment to 'struct gen_pool_chunk *' from
'int' makes pointer from integer without a cast [-Wint-conversion]
lib/genalloc.c: In function 'gen_pool_destroy':
lib/genalloc.c:254:3: error: implicit declaration of function 'vfree'; did you
mean 'kfree'?
Fixes: 6862d2fc8185 ('lib/genalloc.c: use vzalloc_node() to allocate the
bitmap')
Cc: Huang Shijie
Cc: Andrew Morton
Cc: Alexey Skidanov
Signed-off-by: Olof Johansson
---
lib/genalloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/genalloc.c b/lib/genalloc.c
index f365d71cdc774..7e85d1e37a6ea 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
static inline size_t chunk_size(const struct gen_pool_chunk *chunk)
{
--
2.11.0
Re: [PATCH v9 13/27] pwm: jz4740: Use clocks from TCU driver
Hello Paul, On Sat, Jan 05, 2019 at 05:52:46PM -0300, Paul Cercueil wrote: > On Sat, Jan 5, 2019 at 4:45 PM, Uwe Kleine-König > wrote: > > On Thu, Dec 27, 2018 at 07:13:05PM +0100, Paul Cercueil wrote: > > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > > > index 4ed003bc3d8d..0343f0c1238e 100644 > > > --- a/drivers/pwm/Kconfig > > > +++ b/drivers/pwm/Kconfig > > > @@ -202,7 +202,8 @@ config PWM_IMX > > > config PWM_JZ4740 > > > tristate "Ingenic JZ47xx PWM support" > > > depends on MACH_INGENIC > > > -select REGMAP > > > +depends on COMMON_CLK > > > +select INGENIC_TIMER > > > > Did you drop REGMAP on purpose? > > INGENIC_TIMER selects it, so it's still a dependency but indirectly. > Should I restore it? I think noting this in the commit log to not make a reader think (as I did) that it was dropped by mistake is good enough. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v9 12/27] pwm: jz4740: Use regmap from TCU driver
Hello Paul, On Sat, Jan 05, 2019 at 05:46:18PM -0300, Paul Cercueil wrote: > On Sat, Jan 5, 2019 at 4:42 PM, Uwe Kleine-König > wrote: > > On Thu, Dec 27, 2018 at 07:13:04PM +0100, Paul Cercueil wrote: > > > The ingenic-timer "TCU" driver provides us with a regmap, that we > > > can > > > use to safely access the TCU registers. > > > > > > While this driver is devicetree-compatible, it is never (as of now) > > > probed from devicetree, so this change does not introduce a ABI > > > problem > > > with current devicetree files. > > > > Does it change behaviour? If so, how? > > No, it does not change the behaviour. Then this paragraph in the commit log can better be dropped. > > > @@ -113,26 +117,37 @@ static int jz4740_pwm_apply(struct pwm_chip > > > *chip, struct pwm_device *pwm, > > > > > > jz4740_pwm_disable(chip, pwm); > > > > > > -jz4740_timer_set_count(pwm->hwpwm, 0); > > > -jz4740_timer_set_duty(pwm->hwpwm, duty); > > > -jz4740_timer_set_period(pwm->hwpwm, period); > > > +/* Set abrupt shutdown */ > > > +regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm), > > > + TCU_TCSR_PWM_SD, TCU_TCSR_PWM_SD); > > > > I think I already pointed that out before: abrupt mode is wrong. If > > .apply is called with a new set of parameters the currently running > > period with the old values is expected to complete before the new values > > take effect. > > You pointed it, indeed; but I won't change it until I can verify that the > behaviour is correct (which does not seem to be the case even if I leave > this bit cleared). Besides, this is the TCU patchset, fixes and patches > unrelated to the TCU don't belong here. So abrupt mode was already used before? Then maybe note in a comment that this is wrong but kept for now as this change is only refactoring without changing behaviour. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
1aba551c73 ("blk-mq: fix changelog"): BUG: unable to handle kernel NULL pointer dereference at 00000000
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup commit 1aba551c73de605983515118d5ad527594440ccb Author: Greg Kroah-Hartman AuthorDate: Fri Jan 4 14:06:22 2019 +0100 Commit: Greg Kroah-Hartman CommitDate: Sat Jan 5 18:42:10 2019 +0100 blk-mq: fix changelog 7d7009c53a wireless: fix changelog 1aba551c73 blk-mq: fix changelog 6044acd966 lib: WIP, break up +--++++ | | 7d7009c53a | 1aba551c73 | 6044acd966 | +--++++ | boot_successes | 32 | 0 | 0 | | boot_failures| 0 | 22 | 19 | | BUG:unable_to_handle_kernel | 0 | 22 | 19 | | Oops:#[##] | 0 | 22 | 19 | | EIP:debugfs_create_files | 0 | 22 | 19 | | Kernel_panic-not_syncing:Fatal_exception | 0 | 22 | 19 | +--++++ [ 19.240778] parport_pc 00:04: reported by Plug and Play ACPI [ 19.249983] parport0: PC-style at 0x378, irq 7 [PCSPP(,...)] [ 19.259854] lp0: using parport0 (interrupt-driven). [ 19.266789] lp0: console ready [ 19.294331] brd: module loaded [ 19.303672] BUG: unable to handle kernel NULL pointer dereference at [ 19.311670] #PF error: [normal kernel read fault] [ 19.312646] *pdpt = *pde = f000ff53f000ff53 [ 19.312646] Oops: [#1] PTI [ 19.312646] CPU: 0 PID: 1 Comm: swapper Tainted: GT 4.20.0-11094-g1aba551 #440 [ 19.312646] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 19.312646] EIP: debugfs_create_files+0x20/0x60 [ 19.312646] Code: 74 26 00 8d bc 27 00 00 00 00 55 89 e5 56 89 c6 53 83 ec 08 85 c0 74 42 3d 00 f0 ff ff 77 3b 8b 40 10 89 cb 89 90 a4 00 00 00 <8b> 01 85 c0 74 2a 8d 76 00 8d bc 27 00 00 00 00 0f b7 53 04 b9 00 [ 19.312646] EAX: db0c1ae0 EBX: ECX: EDX: d9f41400 [ 19.312646] ESI: db0aa500 EDI: d9f41400 EBP: db45be38 ESP: db45be28 [ 19.312646] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 EFLAGS: 00210287 [ 19.312646] CR0: 80050033 CR2: CR3: 028ca000 CR4: 001406f0 [ 19.312646] Call Trace: [ 19.312646] blk_mq_debugfs_register_sched_hctx+0x36/0x40 [ 19.312646] blk_mq_debugfs_register+0xb1/0xd0 [ 19.312646] blk_register_queue+0xa1/0x170 [ 19.312646] __device_add_disk+0x2af/0x4a0 [ 19.312646] device_add_disk+0x12/0x20 [ 19.312646] loop_add+0x1b9/0x240 [ 19.312646] loop_init+0xfd/0x12f [ 19.312646] ? brd_init+0x15c/0x15c [ 19.312646] do_one_initcall+0x68/0x134 [ 19.312646] ? loglevel+0x47/0x47 [ 19.312646] kernel_init_freeable+0xe1/0x15b [ 19.312646] ? rest_init+0x90/0x90 [ 19.312646] kernel_init+0xb/0x100 [ 19.312646] ? schedule_tail_wrapper+0x9/0x10 [ 19.312646] ret_from_fork+0x19/0x30 [ 19.312646] CR2: [ 19.312646] ---[ end trace 3fa233f5a018a515 ]--- [ 19.312646] EIP: debugfs_create_files+0x20/0x60 # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start 6044acd966af9b2abf150dde97c9092e174f5c32 3fed6ae4b027f9c93be18520f87bd06bdffd196b -- git bisect good 9e34cf7c199ca0088d4704b5c246a915ed336419 # 03:36 G 11 00 0 ti: wl1251: no need to check return value of debugfs_create functions git bisect good 2b1612f9f11109c49b327401b9deb5e7f42ae9aa # 03:48 G 11 00 2 gcov: no need to check return value of debugfs_create functions git bisect good ea485bd98e3c0b4a8ace4f43a6099b28ac37d62d # 03:59 G 11 00 0 l2tp: fix changelog git bisect bad 4f6a5da79aa189934d6ff9244efccb4e166d4648 # 04:11 B 0 10 31 7 gfs: no need to check return value of debugfs_create functions git bisect good 7d7009c53a3be411a6a790ac2788677db27d7286 # 04:24 G 11 00 0 wireless: fix changelog git bisect bad b73f975f76e48705feb505327cd888bb0ec9eb14 # 04:32 B 0 1 15 0 btrfs: no need to check return value of debugfs_create functions git bisect bad 1aba551c73de605983515118d5ad527594440ccb # 04:43 B 0 10 35 11 blk-mq: fix changelog # first bad commit: [1aba551c73de605983515118d5ad527594440ccb] blk-mq: fix changelog git bisect good 7d7009c53a3be411a6a790ac2788677db27d7286 # 04:48 G 30 00 0 wireless: fix changelog # extra tests with debug options git bisect bad 1aba551c73de605983515118d5ad527594440ccb # 05:00 B 0 11 25 0 blk-mq: fix changelog # extra tests on HEAD of
Re: [PATCH v8 1/6] pwm: extend PWM framework with PWM modes
Hello,
On Thu, Jan 03, 2019 at 01:29:44PM +, claudiu.bez...@microchip.com wrote:
> From: Claudiu Beznea
>
> Add basic PWM modes: normal and complementary. These modes should
> differentiate the single output PWM channels from two outputs PWM
> channels. These modes could be set as follow:
> 1. PWM channels with one output per channel:
> - normal mode
> 2. PWM channels with two outputs per channel:
> - normal mode
> - complementary mode
> Since users could use a PWM channel with two output as one output PWM
> channel, the PWM normal mode is allowed to be set for PWM channels with
> two outputs; in fact PWM normal mode should be supported by all PWMs.
I still think that my suggestion that I sent in reply to your v5 using
.alt_duty_cycle and .alt_offset is the better one as it is more generic.
A word about that from Thierry before putting the mode into the pwm API
would be great.
I don't repeat what I wrote there assuming you still remember or are
willing to look it up at
e.g. https://www.spinics.net/lists/linux-pwm/msg08174.html (in the 2nd half
of my mail).
Also I think that if the capabilities function is the way forward adding
support to detect availability of polarity inversion should be
considered. This would also be an opportunity to split the introduction
of the capabilities function and the introduction of complementary mode.
(But my personal preference would be to just let .apply fail when an
unsupported configuration is requested.)
> +static int pwm_get_default_caps(struct pwm_caps *caps)
> +{
> + static const struct pwm_caps default_caps = {
> + .modes_msk = PWM_MODE_BIT(NORMAL),
> + };
> +
> + if (!caps)
> + return -EINVAL;
> +
> + *caps = default_caps;
> +
> + return 0;
> +}
> +
> +/**
> + * pwm_get_caps() - get PWM capabilities of a PWM device
> + * @pwm: PWM device to get the capabilities for
> + * @caps: returned capabilities
> + *
> + * Returns: 0 on success or a negative error code on failure
> + */
> +int pwm_get_caps(const struct pwm_device *pwm, struct pwm_caps *caps)
> +{
> + if (!pwm || !caps)
> + return -EINVAL;
> +
> + if (pwm->chip->ops->get_caps)
> + return pwm->chip->ops->get_caps(pwm->chip, pwm, caps);
> +
> + return pwm_get_default_caps(caps);
I'd drop pwm_get_default_caps (unless you introduce some more callers
later) and fold its implementation into pwm_get_caps.
> +}
> +EXPORT_SYMBOL_GPL(pwm_get_caps);
> [...]
> @@ -53,12 +75,14 @@ enum {
> * @period: PWM period (in nanoseconds)
> * @duty_cycle: PWM duty cycle (in nanoseconds)
> * @polarity: PWM polarity
> + * @modebit: PWM mode bit
> * @enabled: PWM enabled status
> */
> struct pwm_state {
> unsigned int period;
> unsigned int duty_cycle;
> enum pwm_polarity polarity;
> + unsigned long modebit;
I fail to see the upside of storing the mode as 2^mode instead of a
plain enum pwm_mode. Given that struct pwm_state is visible for pwm
users a plain pwm_mode would at least be more intuitive.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v9 14/27] pwm: jz4740: Improve algorithm of clock calculation
Hi,
On Sat, Jan 5, 2019 at 4:57 PM, Uwe Kleine-König
wrote:
On Thu, Dec 27, 2018 at 07:13:06PM +0100, Paul Cercueil wrote:
The previous algorithm hardcoded details about how the TCU clocks
work.
The new algorithm will use clk_round_rate to find the perfect clock
rate
for the PWM channel.
Signed-off-by: Paul Cercueil
---
Notes:
v9: New patch
drivers/pwm/pwm-jz4740.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index c6136bd4434b..dd80a2cf6528 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -110,23 +110,27 @@ static int jz4740_pwm_apply(struct pwm_chip
*chip, struct pwm_device *pwm,
struct jz4740_pwm_chip *jz4740 = to_jz4740(pwm->chip);
struct clk *clk = jz4740->clks[pwm->hwpwm],
*parent_clk = clk_get_parent(clk);
- unsigned long rate, period, duty;
+ unsigned long rate, new_rate, period, duty;
unsigned long long tmp;
- unsigned int prescaler = 0;
rate = clk_get_rate(parent_clk);
- tmp = (unsigned long long)rate * state->period;
- do_div(tmp, 10);
- period = tmp;
- while (period > 0x && prescaler < 6) {
- period >>= 2;
- rate >>= 2;
- ++prescaler;
+ for (;;) {
+ tmp = (unsigned long long)rate * state->period;
+ do_div(tmp, 10);
NSEC_PER_SEC?
Ok, didn't know about it.
+
+ if (tmp <= 0x)
+ break;
+
+ new_rate = clk_round_rate(clk, rate - 1);
+
+ if (new_rate < rate)
+ rate = new_rate;
+ else
+ return -EINVAL;
You are assuming stuff here about the parent clk which isn't
guaranteed
(AFAICT) by the clk framework: If you call clk_round_rate(clk, rate -
1)
this might well return rate even if the clock could run slower than
rate.
It may not be guaranteed by the clock framework itself, but it is
guaranteed
to behave like that on this family of SoCs.
Wouldn't it make sense to start iterating with rate = 0x * 1e9 /
period? Otherwise you get bad configurations if rate is considerable
slower than necessary.
The algorithm will start with 'rate' being the parent clock's rate,
which
will always be the highest rate that the child clock will support.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König
|
Industrial Linux Solutions |
http://www.pengutronix.de/ |
RE: [PATCH v2] Drivers: hv: vmbus: Expose counters for interrupts and full conditions
From: Kimberly Brown Sent: Friday, January 4, 2019 8:35
PM
> static inline void set_channel_pending_send_size(struct vmbus_channel *c,
>u32 size)
> {
> + if (size) {
> + ++c->out_full_total;
> +
> + if (!c->out_full_flag) {
> + ++c->out_full_first;
> + c->out_full_flag = true;
> + }
> + } else {
> + c->out_full_flag = false;
> + }
> +
> c->outbound.ring_buffer->pending_send_sz = size;
> }
>
I think there may be an atomicity problem with the above code. I looked
in the hv_sock code, and didn't see any locks being held when
set_channel_pending_send_size() is called. The original code doesn't need
a lock because it is just storing a single value into pending_send_sz.
In the similar code in hv_ringbuffer_write(), the ring buffer spin lock is held
while the counts are incremented and the out_full_flag is maintained, so all is
good there. But some locking may be needed here. Dexuan knows the hv_sock
code best and can comment on whether there is any higher level synchronization
that prevents multiple threads from running the above code on the same channel.
Even if there is such higher level synchronization, this code probably shouldn't
depend on it for correctness.
Michael
Re: [GIT PULL] MIPS fixes for 4.21
The pull request you sent on Sat, 5 Jan 2019 20:41:57 +: > git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git > tags/mips_fixes_4.21_1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/47f3f4eb7834ea424b0704bffd0d3e3c8ffbc3a1 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH v9 13/27] pwm: jz4740: Use clocks from TCU driver
Hi, On Sat, Jan 5, 2019 at 4:45 PM, Uwe Kleine-König wrote: Hello, On Thu, Dec 27, 2018 at 07:13:05PM +0100, Paul Cercueil wrote: diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 4ed003bc3d8d..0343f0c1238e 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -202,7 +202,8 @@ config PWM_IMX config PWM_JZ4740 tristate "Ingenic JZ47xx PWM support" depends on MACH_INGENIC - select REGMAP + depends on COMMON_CLK + select INGENIC_TIMER Did you drop REGMAP on purpose? INGENIC_TIMER selects it, so it's still a dependency but indirectly. Should I restore it? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v9 12/27] pwm: jz4740: Use regmap from TCU driver
Hi Uwe, On Sat, Jan 5, 2019 at 4:42 PM, Uwe Kleine-König wrote: On Thu, Dec 27, 2018 at 07:13:04PM +0100, Paul Cercueil wrote: The ingenic-timer "TCU" driver provides us with a regmap, that we can use to safely access the TCU registers. While this driver is devicetree-compatible, it is never (as of now) probed from devicetree, so this change does not introduce a ABI problem with current devicetree files. Does it change behaviour? If so, how? No, it does not change the behaviour. @@ -113,26 +117,37 @@ static int jz4740_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, jz4740_pwm_disable(chip, pwm); - jz4740_timer_set_count(pwm->hwpwm, 0); - jz4740_timer_set_duty(pwm->hwpwm, duty); - jz4740_timer_set_period(pwm->hwpwm, period); + /* Set abrupt shutdown */ + regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm), + TCU_TCSR_PWM_SD, TCU_TCSR_PWM_SD); I think I already pointed that out before: abrupt mode is wrong. If .apply is called with a new set of parameters the currently running period with the old values is expected to complete before the new values take effect. You pointed it, indeed; but I won't change it until I can verify that the behaviour is correct (which does not seem to be the case even if I leave this bit cleared). Besides, this is the TCU patchset, fixes and patches unrelated to the TCU don't belong here. Best regards Uwe Kind regards, -Paul
Re: [git pull] vfs.git mount.part1
On Sat, Jan 05, 2019 at 01:31:21PM -0600, Eric W. Biederman wrote: > Not having had a chance to review this code I can't really comment on > the quality of this code. What I do know from a glance is that > you have not removed FS_BINARY_MOUNTDATA. Which is the root cause > of some of the crazy security mount option processing, and is an if > not greater mess than what the security options have been doing with > mount options. > > The FS_BINARY_MOUNTDATA flag is only relevant for coda and for nfs > backwards compatiblity. The FS_BINARY_MOUNTDATA flag is only set on > btrfs to allow calling mount_subtree. ... and thus it can't be killed without having dragged the NFS pile into the entire thing. > I have a set of patches that is finally reasonablly stable and cleans up > all of the mess in the current internal mount apis that should allow > implementing the new mount api to be much less error prone. Quick question: how do you deal with the differences in quoting for selinux options and for everything else? I've no problem with working with you, now that you've resurfaced. Fair warning: no promises of accepting your solutions. Along with a promise to reject anything that breaks existing setups, which your earlier proposals did. With NFS among the victims, IIRC.
Re: [GIT PULL 1/4] Kbuild updates for v4.21
On Sat, Jan 5, 2019 at 12:39 PM Sam Ravnborg wrote: > > Not exactly what you ask for - but we have make V=2 Yeah, that's certainly more convenient than "make --debug". That said, I was more thinking of not any particular "oh, it's recompiling everything" situation (by then it's too late, obviously), but if somebody has been looking at tools for finding and maybe breaking some of our deeper include chains. I know it has come up before (the x86 people did the split some years ago) and then it was all manual. But I was kind of hoping that maybe some of the kbuild people had looked at this? Linus
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Sat, 5 Jan 2019, Linus Torvalds wrote: > > I am still not completely sure what to return in such cases though; we can > > either blatantly lie and always pretend that the pages are resident > > That's what my untested patch did. Or maybe just claim they are all > not present? Thinking about it a little bit more, I believe Vlastimil has a good point with 'non present' potentially causing more bogus activity in userspace in response (in an effort to actually make them present, and failing indefinitely). IOW, I think it's a reasonable expectation that the common scenario is "check if it's present, and if not, try to fault it in" instead of "check if it's present, and if it is, try to evict it". > And again, that patch was entirely untested, so it may be garbage and > have some fundamental problem. I will be travelling for next ~24 hours, but I have just asked our QA guys to run it through some basic battery of testing (which will probably happen on monday anyway). > I also don't know exactly what rule might make most sense, but "you can > write to the file" certainly to me implies that you also could know what > parts of it are in-core. I think it's reasonable; I can't really imagine any sidechannel to a global state be possibly mounted on valid R/W mappings. I'd guess that probably the most interesting here are the code segments of shared libraries, allowing to trace victim's execution. > Who actually _uses_ mincore()? That's probably the best guide to what > we should do. Maybe they open the file read-only even if they are the > owner, and we really should look at file ownership instead. Yeah, well https://codesearch.debian.net/search?q=mincore is a bit too much mess to get some idea quickly I am afraid. -- Jiri Kosina SUSE Labs
[GIT PULL] MIPS fixes for 4.21
Hi Linus, Below is a smattering of early MIPS fixes for 4.21, please pull. Thanks, Paul The following changes since commit adcc81f148d733b7e8e641300c5590a2cdc13bf3: MIPS: math-emu: Write-protect delay slot emulation pages (2018-12-20 10:00:01 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_fixes_4.21_1 for you to fetch changes up to edefae94b7b9f10d5efe32dece5a36e9d9ecc29e: MIPS: OCTEON: mark RGMII interface disabled on OCTEON III (2019-01-02 14:17:24 -0800) A few early MIPS fixes for 4.21: - The Broadcom BCM63xx platform sees a fix for resetting the BCM6368 ethernet switch, and the removal of a platform device we've never had a driver for. - The Alchemy platform sees a few fixes for bitrot that occurred within the past few cycles. - We now enable vectored interrupt support for the MediaTek MT7620 SoC, which makes sense since they're supported by the SoC but in this case also works around a bug relating to the location of exception vectors when using a recent version of U-Boot. - The atomic64_fetch_*_relaxed() family of functions see a fix for a regression in MIPS64 kernels since v4.19. - Cavium Octeon III CN7xxx systems will now disable their RGMII interfaces rather than attempt to enable them & warn about the lack of support for doing so, as they did since initial CN7xxx ethernet support was added in v4.7. - The Microsemi/Microchip MSCC SoCs gain a MAINTAINERS entry. - .mailmap now provides consistency for Dengcheng Zhu's name & current email address. Aaro Koskinen (1): MIPS: OCTEON: mark RGMII interface disabled on OCTEON III Alexandre Belloni (1): MAINTAINERS: Add a maintainer for MSCC MIPS SoCs Dengcheng Zhu (1): mailmap: Update name spelling and email for Dengcheng Zhu Huacai Chen (1): MIPS: Fix a R1_LLSC_WAR logic in atomic.h Jonas Gorski (2): MIPS: BCM63XX: fix switch core reset on BCM6368 MIPS: BCM63XX: drop unused and broken DSP platform device Manuel Lauss (4): MIPS: alchemy: cpu_all_mask is forbidden for clock event devices MIPS: Alchemy: drop DB1000 IrDA support bits MIPS: Alchemy: update cpu-feature-overrides MIPS: Alchemy: update dma masks for devboard devices Stefan Roese (1): MIPS: ralink: Select CONFIG_CPU_MIPSR2_IRQ_VI on MT7620/8 .mailmap | 5 +- MAINTAINERS| 3 +- arch/mips/alchemy/common/time.c| 2 +- arch/mips/alchemy/devboards/db1000.c | 76 -- arch/mips/alchemy/devboards/db1200.c | 24 --- arch/mips/alchemy/devboards/db1300.c | 23 +-- arch/mips/alchemy/devboards/db1550.c | 13 +++- arch/mips/bcm63xx/Makefile | 6 +- arch/mips/bcm63xx/boards/board_bcm963xx.c | 20 -- arch/mips/bcm63xx/dev-dsp.c| 56 arch/mips/bcm63xx/reset.c | 2 +- arch/mips/cavium-octeon/executive/cvmx-helper.c| 3 +- arch/mips/include/asm/atomic.h | 2 +- .../asm/mach-au1x00/cpu-feature-overrides.h| 3 + .../include/asm/mach-bcm63xx/bcm63xx_dev_dsp.h | 14 .../mips/include/asm/mach-bcm63xx/board_bcm963xx.h | 5 -- arch/mips/ralink/Kconfig | 1 + 17 files changed, 70 insertions(+), 188 deletions(-) delete mode 100644 arch/mips/bcm63xx/dev-dsp.c delete mode 100644 arch/mips/include/asm/mach-bcm63xx/bcm63xx_dev_dsp.h signature.asc Description: PGP signature
Re: [PATCH v8 2/6] pwm: add PWM modes
On Thu, Jan 03, 2019 at 01:29:47PM +, claudiu.bez...@microchip.com wrote: > From: Claudiu Beznea > > Add PWM normal and complementary modes. > The Subject line and the commit log don't really match the patch content as it only adds documentation. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [GIT PULL 1/4] Kbuild updates for v4.21
Hi Linus. > But the reason for this email to you is simply to ask whether you > use/have any tools for seeing these kinds of deep include chains. Not exactly what you ask for - but we have make V=2 Example: $ touch include/uapi/linux/elf-em.h $ make V=2 CALLscripts/checksyscalls.sh - due to target missing DESCEND objtool CC init/main.o - due to: include/uapi/linux/elf-em.h CHK include/generated/compile.h CC init/version.o - due to: include/uapi/linux/elf-em.h CC init/do_mounts.o - due to: include/uapi/linux/elf-em.h CC init/do_mounts_initrd.o - due to: include/uapi/linux/elf-em.h CC init/do_mounts_md.o - due to: include/uapi/linux/elf-em.h ... With V=2 kbuild will try to tell you why a target is rebuild. This can sometimes be useful. Here kbuild will tell you: - due to: include/uapi/linux/elf-em.h Which may be a good clue. But you need to figure out yourself why a certain file depends on include/uapi/linux/elf-em.h One way is to look at the .cmd file for a target: $ cat init/.do_mounts_md.o.cmd ... include/linux/module.h \ $(wildcard include/config/modules/tree/lookup.h) \ $(wildcard include/config/module/sig.h) \ $(wildcard include/config/module/unload.h) \ $(wildcard include/config/constructors.h) \ $(wildcard include/config/function/error/injection.h) \ include/linux/kmod.h \ include/linux/umh.h \ include/linux/elf.h \ arch/x86/include/asm/elf.h \ arch/x86/include/asm/user.h \ arch/x86/include/asm/user_64.h \ arch/x86/include/asm/fsgsbase.h \ arch/x86/include/asm/msr-index.h \ arch/x86/include/asm/vdso.h \ $(wildcard include/config/x86/x32.h) \ include/uapi/linux/elf.h \ include/uapi/linux/elf-em.h \ ... In the above all the $(wildcard ...) is the CONFIG_ symbols in the files that trigger a possible dependency on a file representing the CONFIG_ symbol. We can see that the target depends on elf-em.h and if we follow it back we end up with module.h included from do_mounts_md.c Sam
[PATCH 2/2] Input: rotaty-encoder - Add DT binding document
Add DT binding document for rotary-encoder, keycode options.
Signed-off-by: Donghoon Han
---
.../devicetree/bindings/input/rotary-encoder.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt
b/Documentation/devicetree/bindings/input/rotary-encoder.txt
index f99fe5cdeaec..113640079de3 100644
--- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
+++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
@@ -12,6 +12,10 @@ Optional properties:
- rotary-encoder,relative-axis: register a relative axis rather than an
absolute one. Relative axis will only generate +1/-1 events on the input
device, hence no steps need to be passed.
+- rotary-encoder,relative-keys : generate pair of key events. This setting
+ behaves just like relative-axis, generating key events. keycode[2]
+ corresponds -1/1 events.
+- rotary-encoder,relative-keycodes : keycodes for relative-keys
- rotary-encoder,rollover: Automatic rollover when the rotary value becomes
greater than the specified steps or smaller than 0. For absolute axis only.
- rotary-encoder,steps-per-period: Number of steps (stable states) per period.
@@ -48,3 +52,11 @@ Example:
rotary-encoder,encoding = "binary";
rotary-encoder,rollover;
};
+
+ rotary@2 {
+ compatible = "rotary-encoder";
+ gpios = < 21 0>, < 22 0>;
+ rotary-encoder,relative-keys;
+ rotary-encoder,relative-keycode = <103>, <108>;
+ rotary-encoder,steps-per-period = <2>;
+ };
--
2.17.1
[PATCH 1/2] Input: rotary_encoder - Support key events
From: Steven Han
Support generating EV_KEY pair, instead of EV_REL.
Signed-off-by: Donghoon Han
---
drivers/input/misc/rotary_encoder.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/rotary_encoder.c
b/drivers/input/misc/rotary_encoder.c
index 72eee6d55527..180e35884289 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -41,6 +41,8 @@ struct rotary_encoder {
u32 steps;
u32 axis;
bool relative_axis;
+ bool relative_keys;
+ u32 keycodes[2];
bool rollover;
enum rotary_encoder_encoding encoding;
@@ -79,6 +81,10 @@ static void rotary_encoder_report_event(struct
rotary_encoder *encoder)
if (encoder->relative_axis) {
input_report_rel(encoder->input,
encoder->axis, encoder->dir);
+ } else if (encoder->relative_keys) {
+ u32 keycode = encoder->keycodes[encoder->dir > 0];
+ input_event(encoder->input, EV_KEY, keycode, 1);
+ input_event(encoder->input, EV_KEY, keycode, 0);
} else {
unsigned int pos = encoder->pos;
@@ -237,6 +243,16 @@ static int rotary_encoder_probe(struct platform_device
*pdev)
device_property_read_u32(dev, "linux,axis", >axis);
encoder->relative_axis =
device_property_read_bool(dev, "rotary-encoder,relative-axis");
+ encoder->relative_keys =
+ device_property_read_bool(dev, "rotary-encoder,relative-keys");
+ if (encoder->relative_keys) {
+ err = device_property_read_u32_array(dev,
+ "rotary-encoder,relative-keycodes",
+ encoder->keycodes, 2);
+ if (err)
+ dev_err(dev, "unable to get keycodes: %d\n", err);
+ return err;
+ }
encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
if (IS_ERR(encoder->gpios)) {
@@ -260,9 +276,12 @@ static int rotary_encoder_probe(struct platform_device
*pdev)
input->id.bustype = BUS_HOST;
input->dev.parent = dev;
- if (encoder->relative_axis)
+ if (encoder->relative_axis) {
input_set_capability(input, EV_REL, encoder->axis);
- else
+ } else if (encoder->relative_keys) {
+ input_set_capability(input, EV_KEY, encoder->keycodes[0]);
+ input_set_capability(input, EV_KEY, encoder->keycodes[1]);
+ } else
input_set_abs_params(input,
encoder->axis, 0, encoder->steps, 0, 1);
--
2.17.1
[PATCH 0/2] input: rotary-encoder: Support key events
This patchset supports generating EV_KEY, instead of EV_REL. An example could be a volume knob, with key events: - KEY_VOLUMEDOWN / KEY_VOLUMEUP [tested on imx6q platform, full period, half period] Donghoon Han (2): Input: rotary_encoder - Support key events Input: rotaty-encoder - Add DT binding document Documentation/devicetree/bindings/input/rotary-encoder.txt | 12 drivers/input/misc/rotary_encoder.c| 23 +-- 2 files changed, 33 insertions(+), 2 deletions(-)
Re: [GIT PULL] parisc architecture fix for kernel v4.21
The pull request you sent on Sat, 5 Jan 2019 11:40:05 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git > parisc-4.21-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cd08f68c659f42f9ec23b25b9cefd1ef49dc78b5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] arm64: fixes for -rc1
The pull request you sent on Fri, 4 Jan 2019 18:24:27 +: > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/078a5a4faf64fefaf13478a9091782432cad33fa Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] csky patches for the 4.21 merge window
The pull request you sent on Thu, 3 Jan 2019 17:26:00 +0800: > (unable to parse the git remote) has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9ee3b3f4a5eb523ef27675ac2fcd2269b9d68767 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.21-2 tag
The pull request you sent on Sat, 05 Jan 2019 00:00:03 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-4.21-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f1c2f8857c5aa6c92aa903bc06437503422e5925 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] arch/h8300 update
The pull request you sent on Sat, 05 Jan 2019 18:34:34 +0900: > git://git.sourceforge.jp/gitroot/uclinux-h8/linux.git tags/for-4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/670b321f4150bfc8a2261f4db3fcdab21738506b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] ARM: SoC late updates
The pull request you sent on Fri, 4 Jan 2019 14:51:07 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-late has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b23b0ea3708c3dec599966fc856836aca48835b9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
