summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-11-26media: vidtv: fix service_id at SDT tableMauro Carvalho Chehab
The service_id there should be equal to the one used on other tables, otherwise, EIT entries won't be valid. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: fix service typeMauro Carvalho Chehab
As the service currently broadcasts just audio, change the service type to reflect that. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: add a PID entry for the NIT tableMauro Carvalho Chehab
On normal TS streams, the NIT table has its own entry at PAT, but not at PMT. While here, properly handle alloc problems when creating PMT entries. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: properly fill EIT service_idMauro Carvalho Chehab
The EIT header ID field should not contain the network ID, but, instead, the service_id of the program described at EIT. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: fix the network ID rangeMauro Carvalho Chehab
As defined at ETSI TS 101 162, original network IDs up to 0xfebf are reserved for registration at dvb.org. Let's use, instead, an original network ID at the range 0xff00-0xffff, as this is for private temporary usage. As the same value is also used for the network ID, the range 0xff01-0xffff also fits better, as values lower than that depend if the network is used for satellite, terrestrial, cable of CI. While here, move the TS ID to the bridge code, where it is used, and change its value, as it was identical to the value previously used by network ID. While we could keep the same value, let's change it, just to make easier to check for the new code while reading it with DVB tools like dvbinspector. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: improve EIT dataMauro Carvalho Chehab
Place some text at EIT data, and use ISO 8859-15 encoding for the German letter "ü" (u mit umlat) letter. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: cleanup null packet initialization logicMauro Carvalho Chehab
Initialize the destination buffer/size and the initial offset when creating the local var. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: pre-initialize mux arraysMauro Carvalho Chehab
Instead of first zeroing all fields at the mux structs and then filling, do some initialization for the const data when they're created. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: remove some unused functionsMauro Carvalho Chehab
Right now, there's no need to access the length of some tables. So, drop the unused functions. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: do some cleanups at the driverMauro Carvalho Chehab
Do some cleanups at the coding style of the driver: - remove "inline" declarations; - use reverse xmas-tree for local var declarations; - Adjust some indent to avoid breaking 80-cols; - Cleanup some comments. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26drm/nouveau: fix relocations applying logic and a double-freeMatti Hamalainen
Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included a logic-bug which results in the relocations not actually getting applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is never reached. This causes a regression with graphical corruption, triggered when relocations need to be done (for example after a suspend/resume cycle.) Fix by setting *apply_relocs value only if there were more than 0 relocations. Additionally, the never reached code had a leftover u_free() call, which, after fixing the logic, now got called and resulted in a double-free. Fix by removing one u_free(), moving the other and adding check for errors. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Matti Hamalainen <ccr@tnsp.org> Fixes: 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") References: https://gitlab.freedesktop.org/drm/nouveau/-/issues/11 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201120152338.1203257-1-ccr@tnsp.org
2020-11-26media: vidtv: avoid copying data for PES structsMauro Carvalho Chehab
Minimize the number of data copies and initialization at the code, passing them as pointers instead of duplicating the data. The only case where we're keeping the data copy is at vidtv_pes_write_h(), as it needs a copy of the passed arguments. On such case, we're being more explicit. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: avoid data copy when initializing the multiplexerMauro Carvalho Chehab
Initialize the fields of the arguments directly when declaring it, and pass the args as a pointer, instead of copying them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: fix some notes at the tone generatorMauro Carvalho Chehab
The sheet music used to generate the tones had a few polyphonic notes. Due to that, its conversion to a tones sequence had a few errors. Also, due to a bug at the tone generator, it was missing the pause at the initial compass. Fix them. While here, reduce the compass to 100bpm. The music was converted from a Music XML file using this small script: <snip> my $count = 0; my $silent = 0; my $note; my $octave; print "\t"; while (<>) { $note = $1 if (m,\<step\>(.*)\</step\>,); $octave = "_$1" if (m,\<octave\>(.*)\</octave\>,); if (m,\<alter\>1\</alter\>,) { $note .= "S"; $sharp = 1; } if (m,\<rest/\>,) { $note = "SILENT"; $silent = 1; } if (m,\<duration\>(.*)\</duration\>,) { printf "{ NOTE_${note}${octave}, %d},", $1 * 128 / 480; $count++; if ($silent || $count >= 3) { print "\n\t"; $count = 0; $silent = 0; } else { print " "; print " " if (!$sharp); } $sharp = 0; $note = ""; $octave = ""; }; }; print "\n"; </snip> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: fix the tone generator logicMauro Carvalho Chehab
The tone generator logic were repeating the song after the first silent. There's also a wrong logic at the note offset calculus, which may create some noise. Fix it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: fix the name of the programMauro Carvalho Chehab
While the original plan was to use the first movement of the 5th Symphony, it was opted to use the Für Elise song, instead. Fix it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: don't use recursive functionsMauro Carvalho Chehab
The Linux stack is too short. So, using recursive functions is a very bad idea. Convert those into non-recursive ones. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: add error checksMauro Carvalho Chehab
Currently, there are not checks if something gets bad during memory allocation: it will simply use NULL pointers and crash. Add error path at the logic which allocates memory for the MPEG-TS generator code, propagating the errors up to the vidtv_bridge. Now, if something wents bad, start_streaming will return an error that userspace can detect: ERROR DMX_SET_PES_FILTER failed (PID = 0x2000): 12 Cannot allocate memory and the driver doesn't crash. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: reorganize includesMauro Carvalho Chehab
- Place the includes on alphabetical order; - get rid of asm/byteorder.h; - add bug.h at vidtv_s302m.c, as it is needed by inux/fixp-arith.h Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: psi: fix missing assignments in while loopsDaniel W. S. Almeida
Some variables were only assigned once but were used in while loops as if they had been updated at every iteration. Fix this. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: Move s302m specific fields into encoder contextDaniel W. S. Almeida
A few fields used only by the tone generator in the s302m encoder are stored in struct vidtv_encoder. Move them into struct vidtv_s302m_ctx instead. While we are at it: fix a checkpatch warning for long lines. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: psi: extract descriptor chaining code into a helperDaniel W. S. Almeida
The code to append a descriptor to the end of a chain is repeated throughout the psi generator code. Extract it into its own helper function to avoid cluttering. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: psi: Implement an Event Information Table (EIT)Daniel W. S. Almeida
Implement an Event Information Table (EIT) as per EN 300 468 5.2.4. The EIT provides information in chronological order regarding the events contained within each service. For now only present event information is supported. [mchehab+huawei@kernel.org: removed an extra blank line] Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: psi: add a Network Information Table (NIT)Daniel W. S. Almeida
Add a Network Information Table (NIT) as specified in ETSI EN 300 468. This table conveys information relating to the physical organization of the multiplexes carried via a given network and the characteristics of the network itself. It is conveyed in the output of vidtv as packets with TS PID of 0x0010 [mchehab+huawei@kernel.org: removed an extra blank line] Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: extract the initial CRC value to into a #defineDaniel W. S. Almeida
The same constant (0xffffffff) is used in three different functions. Extract it into a #define to avoid repetition. Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-25ch_ktls: lock is not freedRohit Maheshwari
Currently lock gets freed only if timeout expires, but missed a case when HW returns failure and goes for cleanup. Fixes: efca3878a5fb ("ch_ktls: Issue if connection offload fails") Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com> Link: https://lore.kernel.org/r/20201125072626.10861-1-rohitm@chelsio.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net/tls: Protect from calling tls_dev_del for TLS RX twiceMaxim Mikityanskiy
tls_device_offload_cleanup_rx doesn't clear tls_ctx->netdev after calling tls_dev_del if TLX TX offload is also enabled. Clearing tls_ctx->netdev gets postponed until tls_device_gc_task. It leaves a time frame when tls_device_down may get called and call tls_dev_del for RX one extra time, confusing the driver, which may lead to a crash. This patch corrects this racy behavior by adding a flag to prevent tls_device_down from calling tls_dev_del the second time. Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20201125221810.69870-1-saeedm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25Merge branch 'devlink-port-attribute-fixes'Jakub Kicinski
Parav Pandit says: ==================== devlink port attribute fixes This patchset contains 2 small fixes for devlink port attributes. Patch summary: Patch-1 synchronize the devlink port attribute reader with net namespace change operation Patch-2 Ensure to return devlink port's netdevice attributes when netdev and devlink instance belong to same net namespace ==================== Link: https://lore.kernel.org/r/20201125091620.6781-1-parav@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25devlink: Make sure devlink instance and port are in same net namespaceParav Pandit
When devlink reload operation is not used, netdev of an Ethernet port may be present in different net namespace than the net namespace of the devlink instance. Ensure that both the devlink instance and devlink port netdev are located in same net namespace. Fixes: 070c63f20f6c ("net: devlink: allow to change namespaces during reload") Signed-off-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25devlink: Hold rtnl lock while reading netdev attributesParav Pandit
A netdevice of a devlink port can be moved to different net namespace than its parent devlink instance. This scenario occurs when devlink reload is not used. When netdevice is undergoing migration to net namespace, its ifindex and name may change. In such use case, devlink port query may read stale netdev attributes. Fix it by reading them under rtnl lock. Fixes: bfcd3a466172 ("Introduce devlink infrastructure") Signed-off-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25ptp: clockmatrix: bug fix for idtcm_strverscmpMin Li
Feed kstrtou8 with NULL terminated string. Changes since v1: -Use sscanf to get rid of adhoc string parse. Changes since v2: -Check if sscanf returns 3. Fixes: 7ea5fda2b132 ("ptp: ptp_clockmatrix: update to support 4.8.7 firmware") Signed-off-by: Min Li <min.li.xe@renesas.com> Link: https://lore.kernel.org/r/1606273115-25792-1-git-send-email-min.li.xe@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25IB/hfi1: Ensure correct mm is used at all timesDennis Dalessandro
Two earlier bug fixes have created a security problem in the hfi1 driver. One fix aimed to solve an issue where current->mm was not valid when closing the hfi1 cdev. It attempted to do this by saving a cached value of the current->mm pointer at file open time. This is a problem if another process with access to the FD calls in via write() or ioctl() to pin pages via the hfi driver. The other fix tried to solve a use after free by taking a reference on the mm. To fix this correctly we use the existing cached value of the mm in the mmu notifier. Now we can check in the insert, evict, etc. routines that current->mm matched what the notifier was registered for. If not, then don't allow access. The register of the mmu notifier will save the mm pointer. Since in do_exit() the exit_mm() is called before exit_files(), which would call our close routine a reference is needed on the mm. We rely on the mmgrab done by the registration of the notifier, whereas before it was explicit. The mmu notifier deregistration happens when the user context is torn down, the creation of which triggered the registration. Also of note is we do not do any explicit work to protect the interval tree notifier. It doesn't seem that this is going to be needed since we aren't actually doing anything with current->mm. The interval tree notifier stuff still has a FIXME noted from a previous commit that will be addressed in a follow on patch. Cc: <stable@vger.kernel.org> Fixes: e0cf75deab81 ("IB/hfi1: Fix mm_struct use after free") Fixes: 3faa3d9a308e ("IB/hfi1: Make use of mm consistent") Link: https://lore.kernel.org/r/20201125210112.104301.51331.stgit@awfm-01.aw.intel.com Suggested-by: Jann Horn <jannh@google.com> Reported-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-11-25enetc: Let the hardware auto-advance the taprio base-time of 0Vladimir Oltean
The tc-taprio base time indicates the beginning of the tc-taprio schedule, which is cyclic by definition (where the length of the cycle in nanoseconds is called the cycle time). The base time is a 64-bit PTP time in the TAI domain. Logically, the base-time should be a future time. But that imposes some restrictions to user space, which has to retrieve the current PTP time from the NIC first, then calculate a base time that will still be larger than the base time by the time the kernel driver programs this value into the hardware. Actually ensuring that the programmed base time is in the future is still a problem even if the kernel alone deals with this. Luckily, the enetc hardware already advances a base-time that is in the past into a congruent time in the immediate future, according to the same formula that can be found in the software implementation of taprio (in taprio_get_start_time): /* Schedule the start time for the beginning of the next * cycle. */ n = div64_s64(ktime_sub_ns(now, base), cycle); *start = ktime_add_ns(base, (n + 1) * cycle); There's only one problem: the driver doesn't let the hardware do that. It interferes with the base-time passed from user space, by special-casing the situation when the base-time is zero, and replaces that with the current PTP time. This changes the intended effective base-time of the schedule, which will in the end have a different phase offset than if the base-time of 0.000000000 was to be advanced by an integer multiple of the cycle-time. Fixes: 34c6adf1977b ("enetc: Configure the Time-Aware Scheduler via tc-taprio offload") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20201124220259.3027991-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25gro_cells: reduce number of synchronize_net() callsEric Dumazet
After cited commit, gro_cells_destroy() became damn slow on hosts with a lot of cores. This is because we have one additional synchronize_net() per cpu as stated in the changelog. gro_cells_init() is setting NAPI_STATE_NO_BUSY_POLL, and this was enough to not have one synchronize_net() call per netif_napi_del() We can factorize all the synchronize_net() to a single one, right before freeing per-cpu memory. Fixes: 5198d545dba8 ("net: remove napi_hash_del() from driver-facing API") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20201124203822.1360107-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: stmmac: fix incorrect merge of patch upstreamAntonio Borneo
Commit 757926247836 ("net: stmmac: add flexible PPS to dwmac 4.10a") was intended to modify the struct dwmac410_ops, but it got somehow badly merged and modified the struct dwmac4_ops. Revert the modification in struct dwmac4_ops and re-apply it properly in struct dwmac410_ops. Fixes: 757926247836 ("net: stmmac: add flexible PPS to dwmac 4.10a") Signed-off-by: Antonio Borneo <antonio.borneo@st.com> Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20201124223729.886992-1-antonio.borneo@st.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25ipv6: addrlabel: fix possible memory leak in ip6addrlbl_net_initWang Hai
kmemleak report a memory leak as follows: unreferenced object 0xffff8880059c6a00 (size 64): comm "ip", pid 23696, jiffies 4296590183 (age 1755.384s) hex dump (first 32 bytes): 20 01 00 10 00 00 00 00 00 00 00 00 00 00 00 00 ............... 1c 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 ................ backtrace: [<00000000aa4e7a87>] ip6addrlbl_add+0x90/0xbb0 [<0000000070b8d7f1>] ip6addrlbl_net_init+0x109/0x170 [<000000006a9ca9d4>] ops_init+0xa8/0x3c0 [<000000002da57bf2>] setup_net+0x2de/0x7e0 [<000000004e52d573>] copy_net_ns+0x27d/0x530 [<00000000b07ae2b4>] create_new_namespaces+0x382/0xa30 [<000000003b76d36f>] unshare_nsproxy_namespaces+0xa1/0x1d0 [<0000000030653721>] ksys_unshare+0x3a4/0x780 [<0000000007e82e40>] __x64_sys_unshare+0x2d/0x40 [<0000000031a10c08>] do_syscall_64+0x33/0x40 [<0000000099df30e7>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 We should free all rules when we catch an error in ip6addrlbl_net_init(). otherwise a memory leak will occur. Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Link: https://lore.kernel.org/r/20201124071728.8385-1-wanghai38@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpbAnand K Mistry
When spectre_v2_user={seccomp,prctl},ibpb is specified on the command line, IBPB is force-enabled and STIPB is conditionally-enabled (or not available). However, since 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.") the spectre_v2_user_ibpb variable is set to SPECTRE_V2_USER_{PRCTL,SECCOMP} instead of SPECTRE_V2_USER_STRICT, which is the actual behaviour. Because the issuing of IBPB relies on the switch_mm_*_ibpb static branches, the mitigations behave as expected. Since 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP") this discrepency caused the misreporting of IB speculation via prctl(). On CPUs with STIBP always-on and spectre_v2_user=seccomp,ibpb, prctl(PR_GET_SPECULATION_CTRL) would return PR_SPEC_PRCTL | PR_SPEC_ENABLE instead of PR_SPEC_DISABLE since both IBPB and STIPB are always on. It also allowed prctl(PR_SET_SPECULATION_CTRL) to set the IB speculation mode, even though the flag is ignored. Similarly, for CPUs without SMT, prctl(PR_GET_SPECULATION_CTRL) should also return PR_SPEC_DISABLE since IBPB is always on and STIBP is not available. [ bp: Massage commit message. ] Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.") Fixes: 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP") Signed-off-by: Anand K Mistry <amistry@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201110123349.1.Id0cbf996d2151f4c143c90f9028651a5b49a5908@changeid
2020-11-25Merge tag 'media/v5.10-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: - a rand Kconfig fixup for mtk-vcodec - a fix at h264 handling at cedrus codec driver - some warning fixes when config PM is not enabled at marvell-ccic - two fixes at venus codec driver: one related to codec profile and the other one related to a bad error path which causes an OOPS on module re-bind * tag 'media/v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: venus: pm_helpers: Fix kernel module reload media: venus: venc: Fix setting of profile and level media: cedrus: h264: Fix check for presence of scaling matrix media: media/platform/marvell-ccic: fix warnings when CONFIG_PM is not enabled media: mtk-vcodec: fix build breakage when one of VPU or SCP is enabled media: mtk-vcodec: move firmware implementations into their own files
2020-11-25RISC-V: fix barrier() use in <vdso/processor.h>Randy Dunlap
riscv's <vdso/processor.h> uses barrier() so it should include <asm/barrier.h> Fixes this build error: CC [M] drivers/net/ethernet/emulex/benet/be_main.o In file included from ./include/vdso/processor.h:10, from ./arch/riscv/include/asm/processor.h:11, from ./include/linux/prefetch.h:15, from drivers/net/ethernet/emulex/benet/be_main.c:14: ./arch/riscv/include/asm/vdso/processor.h: In function 'cpu_relax': ./arch/riscv/include/asm/vdso/processor.h:14:2: error: implicit declaration of function 'barrier' [-Werror=implicit-function-declaration] 14 | barrier(); This happens with a total of 5 networking drivers -- they all use <linux/prefetch.h>. rv64 allmodconfig now builds cleanly after this patch. Fixes fallout from: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") Fixes: ad5d1122b82f ("riscv: use vDSO common flow to reduce the latency of the time-related functions") Reported-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-11-25RISC-V: Add missing jump label initializationAnup Patel
The jump_label_init() should be called from setup_arch() very early for proper functioning of jump label support. Fixes: ebc00dde8a97 ("riscv: Add jump-label implementation") Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-11-25riscv: Explicitly specify the build id style in vDSO Makefile againNathan Chancellor
Commit a96843372331 ("kbuild: explicitly specify the build id style") explicitly set the build ID style to SHA1. Commit c2c81bb2f691 ("RISC-V: Fix the VDSO symbol generaton for binutils-2.35+") undid this change, likely unintentionally. Restore it so that the build ID style stays consistent across the tree regardless of linker. Fixes: c2c81bb2f691 ("RISC-V: Fix the VDSO symbol generaton for binutils-2.35+") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Bill Wendling <morbo@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-11-25efi: EFI_EARLYCON should depend on EFIGeert Uytterhoeven
CONFIG_EFI_EARLYCON defaults to yes, and thus is enabled on systems that do not support EFI, or do not have EFI support enabled, but do satisfy the symbol's other dependencies. While drivers/firmware/efi/ won't be entered during the build phase if CONFIG_EFI=n, and drivers/firmware/efi/earlycon.c itself thus won't be built, enabling EFI_EARLYCON does force-enable CONFIG_FONT_SUPPORT and CONFIG_ARCH_USE_MEMREMAP_PROT, and CONFIG_FONT_8x16, which is undesirable. Fix this by making CONFIG_EFI_EARLYCON depend on CONFIG_EFI. This reduces kernel size on headless systems by more than 4 KiB. Fixes: 69c1f396f25b805a ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20201124191646.3559757-1-geert@linux-m68k.org Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-11-25efivarfs: revert "fix memory leak in efivarfs_create()"Ard Biesheuvel
The memory leak addressed by commit fe5186cf12e3 is a false positive: all allocations are recorded in a linked list, and freed when the filesystem is unmounted. This leads to double frees, and as reported by David, leads to crashes if SLUB is configured to self destruct when double frees occur. So drop the redundant kfree() again, and instead, mark the offending pointer variable so the allocation is ignored by kmemleak. Cc: Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com> Fixes: fe5186cf12e3 ("efivarfs: fix memory leak in efivarfs_create()") Reported-by: David Laight <David.Laight@aculab.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-11-25efi/efivars: Set generic ops before loading SSDTAmadeusz Sławiński
Efivars allows for overriding of SSDT tables, however starting with commit bf67fad19e493b ("efi: Use more granular check for availability for variable services") this use case is broken. When loading SSDT generic ops should be set first, however mentioned commit reversed order of operations. Fix this by restoring original order of operations. Fixes: bf67fad19e493b ("efi: Use more granular check for availability for variable services") Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20201123172817.124146-1-amadeuszx.slawinski@linux.intel.com Tested-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-11-25RDMA/i40iw: Address an mmap handler exploit in i40iwShiraz Saleem
i40iw_mmap manipulates the vma->vm_pgoff to differentiate a push page mmap vs a doorbell mmap, and uses it to compute the pfn in remap_pfn_range without any validation. This is vulnerable to an mmap exploit as described in: https://lore.kernel.org/r/20201119093523.7588-1-zhudi21@huawei.com The push feature is disabled in the driver currently and therefore no push mmaps are issued from user-space. The feature does not work as expected in the x722 product. Remove the push module parameter and all VMA attribute manipulations for this feature in i40iw_mmap. Update i40iw_mmap to only allow DB user mmapings at offset = 0. Check vm_pgoff for zero and if the mmaps are bound to a single page. Cc: <stable@kernel.org> Fixes: d37498417947 ("i40iw: add files for iwarp interface") Link: https://lore.kernel.org/r/20201125005616.1800-2-shiraz.saleem@intel.com Reported-by: Di Zhu <zhudi21@huawei.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-11-25arm64: tegra: Fix Tegra234 VDK node namesJon Hunter
When the device-tree board file was added for the Tegra234 VDK simulator it incorrectly used the names 'cbb' and 'sdhci' instead of 'bus' and 'mmc', respectively. The names 'bus' and 'mmc' are required by the device-tree json-schema validation tools. Therefore, fix this by renaming these nodes accordingly. Fixes: 639448912ba1 ("arm64: tegra: Initial Tegra234 VDK support") Reported-by: Ashish Singhal <ashishsingha@nvidia.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-11-25arm64: tegra: Wrong AON HSP reg property sizeDipen Patel
The AON HSP node's "reg" property size 0xa0000 will overlap with other resources. This patch fixes that wrong value with correct size 0x90000. Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Dipen Patel <dipenp@nvidia.com> Fixes: a38570c22e9d ("arm64: tegra: Add nodes for TCU on Tegra194") Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-11-25arm64: tegra: Fix USB_VBUS_EN0 regulator on Jetson TX1JC Kuo
USB host mode is broken on the OTG port of Jetson TX1 platform because the USB_VBUS_EN0 regulator (regulator@11) is being overwritten by the vdd-cam-1v2 regulator. This commit rearranges USB_VBUS_EN0 to be regulator@14. Fixes: 257c8047be44 ("arm64: tegra: jetson-tx1: Add camera supplies") Cc: stable@vger.kernel.org Signed-off-by: JC Kuo <jckuo@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-11-25arm64: tegra: Correct the UART for Jetson Xavier NXJon Hunter
The Jetson Xavier NX board routes UARTA to the 40-pin header and UARTC to a 12-pin debug header. The UARTs can be used by either the Tegra Combined UART (TCU) driver or the Tegra 8250 driver. By default, the TCU will use UARTC on Jetson Xavier NX. Currently, device-tree for Xavier NX enables the TCU and the Tegra 8250 node for UARTC. Fix this by disabling the Tegra 8250 node for UARTC and enabling the Tegra 8250 node for UARTA. Fixes: 3f9efbbe57bc ("arm64: tegra: Add support for Jetson Xavier NX") Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-11-25arm64: tegra: Disable the ACONNECT for Jetson TX2Jon Hunter
Commit ff4c371d2bc0 ("arm64: defconfig: Build ADMA and ACONNECT driver") enable the Tegra ADMA and ACONNECT drivers and this is causing resume from system suspend to fail on Jetson TX2. Resume is failing because the ACONNECT driver is being resumed before the BPMP driver, and the ACONNECT driver is attempting to power on a power-domain that is provided by the BPMP. While a proper fix for the resume sequencing problem is identified, disable the ACONNECT for Jetson TX2 temporarily to avoid breaking system suspend. Please note that ACONNECT driver is used by the Audio Processing Engine (APE) on Tegra, but because there is no mainline support for APE on Jetson TX2 currently, disabling the ACONNECT does not disable any useful feature at the moment. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>