Currently there are 3 different variants of read_id implementation:
1. opcode only. Found in GD5FxGQ4xF.
2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
3. opcode + 1 dummy byte. Found in other currently supported chips.
Original implementation was for variant 1 and let detect function
of chips with variant 2 and 3 to ignore the first byte. This isn't
robust:
1. For chips of variant 2, if SPI master doesn't keep MOSI low
during read, chip will get a random id offset, and the entire id
buffer will shift by that offset, causing detect failure.
2. For chips of variant 1, if it happens to get a devid that equals
to manufacture id of variant 2 or 3 chips, it'll get incorrectly
detected.
This patch reworks detect procedure to address problems above. New
logic do detection for all variants separatedly, in 1-2-3 order.
Since all current detect methods do exactly the same id matching
procedure, unify them into core.c and remove detect method from
manufacture_ops.
Tested on GD5F1GQ4UAYIG and W25N01GVZEIG.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200208074439.146296-1-gch981213@gmail.com
Add a comment above NAND_MFR_TOSHIBA and SPINAND_MFR_TOSHIBA definitions
that Toshiba and Kioxia ID are the same.
Since its independence from Toshiba Group, Toshiba memory Co has become
Kioxia Co.
Signed-off-by: Yoshio Furuyama <ytc-mb-yfuruyama7@kioxia.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/1581051561-7302-1-git-send-email-ytc-mb-yfuruyama7@kioxia.com
If the write protect signal from this IP is connected to the NAND
device, this IP can handle the WP# pin via the WRITE_PROTECT
register.
The Denali NAND Flash Memory Controller User's Guide describes
this register like follows:
When the controller is in reset, the WP# pin is always asserted
to the device. Once the reset is removed, the WP# is de-asserted.
The software will then have to come and program this bit to
assert/de-assert the same.
1 - Write protect de-assert
0 - Write protect assert
The default value is 1, so the write protect is de-asserted after
the reset is removed. The driver can write to the device unless
someone has explicitly cleared register before booting the kernel.
The boot ROM of some UniPhier SoCs (LD4, Pro4, sLD8, Pro5) is the
case; the boot ROM clears the WRITE_PROTECT register when the system
is booting from the NAND device, so the NAND device becomes read-only.
Set it to 1 in the driver in order to allow the write access to the
device.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200127123934.11847-1-yamada.masahiro@socionext.com
The used way to compute jiffies timeout brokes when
jiffie difference is 1.
Assume that nand_soft_waitrdy is called with timeout_ms==1.
Jiffies are 1000 for example (assume something more like 1000.99
- just before incrementing to 1001).
We compute timeout_ms = 1000+msecs_to_jiffies(1) = 1001.
nand_read_data_op is called for the first time and returns 0.
During the call jiffies changes to 1001 thus "while loop" ends
here (wrongly). Notice that routine was called with expected timeout
1ms but actual timeout used was something between 0...1ms.
Fixes STM32MP1 FMC2 NAND controller which sometimes failed
exactly in this way.
Signed-off-by: Martin Devera <devik@eaxlabs.cz>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200116135431.17480-1-devik@eaxlabs.cz
Do not depend on dwfl_module_addrsym() because it can fail on user-space
shared libraries.
Actually, same bug was fixed by commit 664fee3dc3 ("perf probe: Do not
use dwfl_module_addrsym if dwarf_diename finds symbol name"), but commit
07d3698578 ("perf probe: Fix wrong address verification) reverted to
get actual symbol address from symtab.
This fixes it again by getting symbol address from DIE, and only if the
DIE has only address range, it uses dwfl_module_addrsym().
Fixes: 07d3698578 ("perf probe: Fix wrong address verification)
Reported-by: Alexandre Ghiti <alex@ghiti.fr>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Alexandre Ghiti <alex@ghiti.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sashal@kernel.org>
Link: http://lore.kernel.org/lkml/158281812176.476.14164573830975116234.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When we put an event with multiple probes, perf-probe fails to delete
with filters. This comes from a failure to list up the event name
because of overwrapping its name.
To fix this issue, skip to list up the event which has same name.
Without this patch:
# perf probe -l \*
probe_perf:map__map_ip (on perf_sample__fprintf_brstackoff:21@
probe_perf:map__map_ip (on perf_sample__fprintf_brstackoff:25@
probe_perf:map__map_ip (on append_inlines:12@util/machine.c in
probe_perf:map__map_ip (on unwind_entry:19@util/machine.c in /
probe_perf:map__map_ip (on map__map_ip@util/map.h in /home/mhi
probe_perf:map__map_ip (on map__map_ip@util/map.h in /home/mhi
# perf probe -d \*
"*" does not hit any event.
Error: Failed to delete events. Reason: No such file or directory (Code: -2)
With it:
# perf probe -d \*
Removed event: probe_perf:map__map_ip
#
Fixes: 72363540c0 ("perf probe: Support multiprobe event")
Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Reported-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lore.kernel.org/lkml/158287666197.16697.7514373548551863562.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
request_irq() is preferred over setup_irq(). Invocations of setup_irq()
occur after memory allocators are ready.
Per tglx[1], setup_irq() existed in olden days when allocators were not
ready by the time early interrupts were initialized.
Hence replace setup_irq() by request_irq().
[1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos
Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
ADD_CONFIG_TERM accesses term->weak, however, in get_config_chgs this
value is accessed outside of the list_for_each_entry and references
invalid memory. Add an argument for ADD_CONFIG_TERM for weak and set it
to false in the get_config_chgs case.
This bug was cause by clang's address sanitizer and libfuzzer. It can be
reproduced with a command line of:
perf stat -a -e i/bs,tsc,L2/o
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: clang-built-linux@googlegroups.com
Link: http://lore.kernel.org/lkml/20200307073121.203816-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We are parsing SSBI gpios as fourcell fwspecs but they are
twocell. Probably a simple copy-and-paste bug.
Tested on the APQ8060 DragonBoard and after this ethernet
and MMC card detection works again.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: stable@vger.kernel.org
Reviewed-by: Brian Masney <masneyb@onstation.org>
Fixes: ae436fe810 ("pinctrl: ssbi-gpio: convert to hierarchical IRQ helpers in gpio core")
Link: https://lore.kernel.org/r/20200306143416.1476250-1-linus.walleij@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch fixes an off-by-one error in strncpy size argument in
tools/perf/util/map.c. The issue is that in:
strncmp(filename, "/system/lib/", 11)
the passed string literal: "/system/lib/" has 12 bytes (without the NULL
byte) and the passed size argument is 11. As a result, the logic won't
match the ending "/" byte and will pass filepaths that are stored in
other directories e.g. "/system/libmalicious/bin" or just
"/system/libmalicious".
This functionality seems to be present only on Android. I assume the
/system/ directory is only writable by the root user, so I don't think
this bug has much (or any) security impact.
Fixes: eca8183699 ("perf tools: Add automatic remapping of Android libraries")
Signed-off-by: disconnect3d <dominik.b.czarnota@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Changbin Du <changbin.du@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: John Keeping <john@metanate.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michael Lentine <mlentine@google.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20200309104855.3775-1-dominik.b.czarnota@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fix the following kerneldoc warning and while at it also the doc for the
corresponding vfunc hook.
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs'
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304150918.25473-1-imre.deak@intel.com
- Drop CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m (depends on
BRIDGE_NETFILTER, which is disabled by default since commit
98bda63e20 ("net: disable BRIDGE_NETFILTER by default")),
- Enable modular build of the WireGuard secure network tunnel,
- Drop CONFIG_CRYPTO_LIB_{BLAKE2S,CHACHA20POLY1305,CURVE25519}=m
(auto-enabled by CONFIG_WIREGUARD).
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200227183748.GA31018@embeddedor
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Classic m68k with MMU was converted to generic hardirqs a long time ago,
and there are no longer include dependency issues preventing the direct
use of asm-generic/hardirq.h.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Link: https://lore.kernel.org/r/20200112174854.2726-1-geert@linux-m68k.org
Replace the call to the custom non-existing function by a standard
BUILD_BUG() invocation.
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20200112171521.22443-1-geert@linux-m68k.org
The kerneldoc for dio_bus_match() was obviously copied from
dio_match_device(), but wasnt't updated for the different calling
context and semantics.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20200112165613.20960-3-geert@linux-m68k.org
The kerneldoc for zorro_bus_match() was obviously copied from
zorro_match_device(), but wasnt't updated for the different calling
context and semantics.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20200112164949.20196-3-geert@linux-m68k.org
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20191120133721.12178-1-krzk@kernel.org
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
For security, don't display the kernel's virtual memory layout.
Kees Cook points out:
"These have been entirely removed on other architectures, so let's
just do the same for ia32 and remove it unconditionally."
071929dbdd ("arm64: Stop printing the virtual memory layout")
1c31d4e96b ("ARM: 8820/1: mm: Stop printing the virtual memory layout")
31833332f7 ("m68k/mm: Stop printing the virtual memory layout")
fd8d0ca256 ("parisc: Hide virtual kernel memory layout")
adb1fe9ae2 ("mm/page_alloc: Remove kernel address exposure in free_reserved_area()")
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Acked-by: Tycho Andersen <tycho@tycho.ws>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The MIDI input event parser of the LINE6 driver may enter into an
endless loop when the unexpected data sequence is given, as it tries
to continue the secondary bytes without termination. Also, when the
input data is too short, the parser returns a negative error, while
the caller doesn't handle it properly. This would lead to the
unexpected behavior as well.
This patch addresses those issues by checking the return value
correctly and handling the one-byte event in the parser properly.
The bug was reported by syzkaller.
Reported-by: syzbot+cce32521ee0a824c21f7@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/000000000000033087059f8f8fa3@google.com
Link: https://lore.kernel.org/r/20200309095922.30269-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Peter Zijlstra <peterz@infradead.org> wrote:
"In order to facilitate Will's READ_ONCE() patches, we need to fix
m68k/motorola to not have a giant pmd_t. These patches do so and are
tested using ARAnyM/68040."
A resource will be a shmem based resource or a (planned)
vram based resource, so it makes sense to factor out common fields
(resource handle, dumb).
v2: move mapped field to shmem object
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-1-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This reverts commit a522f1d0c3.
With cpu_pm handling fixed for omaps, and with gpio-omap now returning
notify error on pending interrupts, we can drop the old workaround for
seeing if there may be pending edge interrupts.
Depends-on: ARM: OMAP2+: Handle errors for cpu_pm
Depends-on: gpio: omap: Block idle on pending gpio interrupts
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200304225433.37336-4-tony@atomide.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With the SoC cpuidle handling fixed for cpu_pm, we can now start to
return NOTIFY_BAD if there there are pending gpio interrupts.
This way the deeper SoC idle states can get blocked, and gpio latency
is improved in some cases. Note that this will not help with the
latency if the SoC has already entered a deeper idle state.
Note that this patch depends on cpu_pm properly handling the errors
returned by notifiers. For omap variants, this is fixed with patch
"ARM: OMAP2+: Handle errors for cpu_pm".
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200304225433.37336-3-tony@atomide.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
We need to check for errors when calling cpu_pm_enter() and
cpu_cluster_pm_enter(). And we need to bail out on errors as
otherwise we can enter a deeper idle state when not desired.
I'm not aware of the lack of error handling causing issues yet,
but we need this at least for blocking deeper idle states when
a GPIO instance has pending interrupts.
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20200304225433.37336-2-tony@atomide.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its
only caller.
The diff chooses it to so it by moving drm_pci_agp_destroy earlier, but
the important bit is moving the #ifdef earlier before drm_pci_agp_init.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307093702.2269-1-chris@chris-wilson.co.uk
This patch adds missing required properties of power-domains and resets.
Fortunately, no one has this device node for now, so that we don't
need to think of backward compatibility.
Fixes: 311accb645 ("clk: renesas: rcar-usb2-clock-sel: Add R-Car USB 2.0 clock selector PHY")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1583304137-28482-3-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Since the hardware requires to enable both USB 2.0 host and peripheral
functional clock, this patch fixes the documentation.
Fortunately, no one has this device node for now, so that we don't
need to think of backward compatibility.
Fixes: 311accb645 ("clk: renesas: rcar-usb2-clock-sel: Add R-Car USB 2.0 clock selector PHY")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1583304137-28482-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Each OSS PCM plugins allocate its internal buffer per pre-calculation
of the max buffer size through the chain of plugins (calling
src_frames and dst_frames callbacks). This works for most plugins,
but the rate plugin might behave incorrectly. The calculation in the
rate plugin involves with the fractional position, i.e. it may vary
depending on the input position. Since the buffer size
pre-calculation is always done with the offset zero, it may return a
shorter size than it might be; this may result in the out-of-bound
access as spotted by fuzzer.
This patch addresses those possible buffer overflow accesses by simply
setting the upper limit per the given buffer size for each plugin
before src_frames() and after dst_frames() calls.
Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/000000000000b25ea005a02bcf21@google.com
Link: https://lore.kernel.org/r/20200309082148.19855-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Alex Elder says:
====================
net: introduce Qualcomm IPA driver (UPDATED)
This series presents the driver for the Qualcomm IP Accelerator (IPA).
This is version 2 of this updated series. It includes the following
small changes since the previous version:
- Now based on net-next instead of v5.6-rc
- Config option now named CONFIG_QCOM_IPA
- Some minor cleanup in the GSI code
- Small change to replenish logic
- No longer depends on remoteproc bug fixes
What follows is the basically same explanation as was posted previously.
-Alex
I have posted earlier versions of this code previously, but it has
undergone quite a bit of development since the last time, so rather
than calling it "version 3" I'm just treating it as a new series
(indicating it's been updated in this message). The fast/data path
is the same as before. But the driver now (nearly) supports a
second platform, its transaction handling has been generalized
and improved, and modem activities are now handled in a more
unified way.
This series is available (based on net-next in branch "ipa_updated-v2"
in this git repository:
https://git.linaro.org/people/alex.elder/linux.git
The branch depends on other one other small patch that I sent out
for review earlier.
https://lore.kernel.org/lkml/20200306042302.17602-1-elder@linaro.org/
I want to address some of the discussion that arose last time.
First, there was the WWAN discussion. Here's the history:
- This was last posted nine months ago.
- Reviewers at that time favored developing a new WWAN subsystem that
would be used for managing devices like this. And the suggestion
was to not accept this driver until that could be developed.
- Along the way, Apple acquired much of Intel's modem business.
And as a result, the generic framework became less pressing.
- I did participate in the WWAN subsystem design however, and
although it went dormant for a while it's been resurrected:
https://lore.kernel.org/netdev/20200225100053.16385-1-johannes@sipsolutions.net/
- Unfortunately the proposed WWAN design was not an easy fit
with Qualcomm's integrated modem interfaces. Given that
rmnet is a supported link type for in the upstream "iproute2"
package (more on this below), I have opted not to integrate
with any WWAN subsystem.
So in summary, this driver does not integrate with a generic WWAN
framework. And I'd like it to be accepted upstream despite that.
Next, Arnd Bergmann had some concerns about flow control. (Note:
some of my discussions with Arnd about this were offline.) The
overall architecture here also involves the "rmnet" driver:
drivers/net/ethernet/qualcomm/rmnet
The rmnet driver presents a network device for use. It connects
with another network device presented, by the IPA driver. The
rmnet driver wraps (and unwraps) packets transferred to (and from)
the IPA driver with QMAP headers.
---------------
| rmnet_data0 | <-- "real" netdev
---------------
|| }- QMAP spoken here
--------------
| rmnet_ipa0 | <-- also netdev, transporting QMAP packets
--------------
||
--------------
( IPA hardware )
--------------
Arnd's concern was that the rmnet_data0 network device does not
have the benefit of information about the state of the underlying
IPA hardware in order to be effective in controlling TX flow.
The feared result is over-buffering of TX packets (bufferbloat).
I began working on some simple experiments to see whether (or how
much) his concern was warranted. But it turned out that completing
these experiments was much more work than had been hoped.
The rmnet driver is present in the upstream kernel. There is also
support for the rmnet link type in the upstream "ip" user space
command in the "iproute2" package. Changing the layering of rmnet
over IPA likely involves deprecating the rmnet driver and its
support in "iproute2". I would really rather not go down that
path.
There is precedent for this sort of layering of network devices
(L2TP, VLAN). And any architecture like this would suffer the
issues Arnd mentioned; the problem is not limited to rmnet and IPA.
I do think this is a problem worth solving, but the prudent thing
to do might be to try to solve it more generally.
So to summarize on this issue, this driver does not attempt to
change the way the rmnet and IPA drivers work together. And even
though I think Arnd's concerns warrant more investigation, I'd like
this driver to to be accepted upstream without any change to this
architecture.
Finally, a more technical description for the series, and some
acknowledgements to some people who contributed to it.
The IPA is a component present in some Qualcomm SoCs that allows
network functions such as aggregation, filtering, routing, and NAT
to be performed without active involvement of the main application
processor (AP).
In this initial patch series these advanced features are not
implemented. The IPA driver simply provides a network interface
that makes the modem's LTE network available in Linux. This initial
series supports only the Qualcomm SDM845 SoC. The Qualcomm SC7180
SoC is partially supported, and support for other platforms will
follow.
This code is derived from a driver developed by Qualcomm. A version
of the original source can be seen here:
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree
in the "drivers/platform/msm/ipa" directory. Many were involved in
developing this, but the following individuals deserve explicit
acknowledgement for their substantial contributions:
Abhishek Choubey
Ady Abraham
Chaitanya Pratapa
David Arinzon
Ghanim Fodi
Gidon Studinski
Ravi Gummadidala
Shihuan Liu
Skylar Chang
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Add IPA-related nodes and definitions to "sdm845.dtsi".
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add an entry in the MAINTAINERS file for the Qualcomm IPA driver
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
