aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-08-12platform/x86: acer-wmi: Use backlight power constantsThomas Zimmermann1-2/+1
Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality or semantics. Signed-off-by: Thomas Zimmermann <[email protected]> Cc: "Lee, Chun-Yi" <[email protected]> Cc: Hans de Goede <[email protected]> Cc: "Ilpo Järvinen" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-08-12platform/x86/intel/pmt: Use PMT callbacksDavid E. Box3-12/+32
PMT providers may require device specific actions before their telemetry may be read. If the read_telem() is assigned, call it instead of memcpy_fromio() and return. Since this needs to be done in multiple locations, add pmt_telem_read_mmio() as a wrapper function to perform this and any other needed checks. Reviewed-by: Ilpo Järvinen <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Signed-off-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-08-12platform/x86/intel/vsec: Add PMT read callbacksDavid E. Box2-0/+16
Some PMT providers require device specific actions before their telemetry can be read. Provide assignable PMT read callbacks to allow providers to perform those actions. Reviewed-by: Ilpo Järvinen <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Signed-off-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-08-12platform/x86/intel/vsec.h: Move to include/linuxDavid E. Box10-17/+41
Some drivers outside of PDX86 need access to the vsec header. Move it to include/linux to make it easier to include. Reviewed-by: Ilpo Järvinen <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Signed-off-by: David E. Box <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-08-12ALSA: usb-audio: Support multiple control interfacesKarol Kosik12-47/+127
Registering Numark Party Mix II fails with error 'bogus bTerminalLink 1'. The problem stems from the driver not being able to find input/output terminals required to configure audio streaming. The information about those terminals is stored in AudioControl Interface. Numark device contains 2 AudioControl Interfaces and the driver checks only one of them. According to the USB standard, a device can have multiple audio functions, each represented by Audio Interface Collection. Every audio function is considered to be closed box and will contain unique AudioControl Interface and zero or more AudioStreaming and MIDIStreaming Interfaces. The Numark device adheres to the standard and defines two audio functions: - MIDIStreaming function - AudioStreaming function It starts with MIDI function, followed by the audio function. The driver saves the first AudioControl Interface in `snd_usb_audio` structure associated with the entire device. It then attempts to use this interface to query for terminals and clocks. However, this fails because the correct information is stored in the second AudioControl Interface, defined in the second Audio Interface Collection. This patch introduces a structure holding association between each MIDI/Audio Interface and its corresponding AudioControl Interface, instead of relying on AudioControl Interface defined for the entire device. This structure is populated during usb probing phase and leveraged later when querying for terminals and when sending USB requests. Alternative solutions considered include: - defining a quirk for Numark where the order of interface is manually changed, or terminals are hardcoded in the driver. This solution would have fixed only this model, though it seems that device is USB compliant, and it also seems that other devices from this company may be affected. What's more, it looks like products from other manufacturers have similar problems, i.e. Rane One DJ console - keeping a list of all AudioControl Interfaces and querying all of them to find required information. That would have solved my problem and have low probability of breaking other devices, as we would always start with the same logic of querying first AudioControl Interface. This solution would not have followed the standard though. This patch preserves the `snd_usb_audio.ctrl_intf` variable, which holds the first AudioControl Interface, and uses it as a fallback when some interfaces are not parsed correctly and lack an associated AudioControl Interface, i.e., when configured via quirks. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217865 Signed-off-by: Karol Kosik <[email protected]> Link: https://patch.msgid.link/AS8P190MB1285893F4735C8B32AD3886BEC852@AS8P190MB1285.EURP190.PROD.OUTLOOK.COM Signed-off-by: Takashi Iwai <[email protected]>
2024-08-12drm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()`Maíra Canal1-3/+11
When enabling UBSAN on Raspberry Pi 5, we get the following warning: [ 387.894977] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/v3d/v3d_sched.c:320:3 [ 387.903868] index 7 is out of range for type '__u32 [7]' [ 387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G WC 6.10.3-v8-16k-numa #151 [ 387.919166] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 387.925961] Workqueue: v3d_csd drm_sched_run_job_work [gpu_sched] [ 387.932525] Call trace: [ 387.935296] dump_backtrace+0x170/0x1b8 [ 387.939403] show_stack+0x20/0x38 [ 387.942907] dump_stack_lvl+0x90/0xd0 [ 387.946785] dump_stack+0x18/0x28 [ 387.950301] __ubsan_handle_out_of_bounds+0x98/0xd0 [ 387.955383] v3d_csd_job_run+0x3a8/0x438 [v3d] [ 387.960707] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ 387.966862] process_one_work+0x62c/0xb48 [ 387.971296] worker_thread+0x468/0x5b0 [ 387.975317] kthread+0x1c4/0x1e0 [ 387.978818] ret_from_fork+0x10/0x20 [ 387.983014] ---[ end trace ]--- This happens because the UAPI provides only seven configuration registers and we are reading the eighth position of this u32 array. Therefore, fix the out-of-bounds read in `v3d_csd_job_run()` by accessing only seven positions on the '__u32 [7]' array. The eighth register exists indeed on V3D 7.1, but it isn't currently used. That being so, let's guarantee that it remains unused and add a note that it could be set in a future patch. Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x") Reported-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-12platform/x86/intel/pmc: Show live substate requirementsKane Chen1-1/+11
While debugging runtime s0ix, we do need to check which required IPs are not power gated. This patch adds code to show live substate status vs requirements in sys/kernel/debug/pmc_core/substate_requirements to help runtime s0ix debug. Signed-off-by: Kane Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-08-12drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()Chun-Kuang Hu1-42/+4
Use cmdq_pkt_create() and cmdq_pkt_destroy() common function instead of implementing drm version. Signed-off-by: Chun-Kuang Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
2024-08-12drm/mediatek: Use cmdq_pkt_eoc() instead of cmdq_pkt_finalize()Chun-Kuang Hu1-1/+1
For some client driver, it want to reduce latency between excuting previous packet command and next packet command, so append jump command to the end of previous packet and the jump destination address is the start address of next packet command buffer. Before next packet exist, the previous packet has no information of where to jump to, so append nop command first. When next packet exist, change nop command to jump command. For mediatek drm driver, it never has next packet, so appending nop command is redundant. Because cmdq_pkt_finalize() would append nop command, so change calling cmdq_pkt_finalize() to cmdq_pkt_eoc() to prevent append redundant nop command. Signed-off-by: Chun-Kuang Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
2024-08-12Merge branch 'ethtool-rss-driver-tweaks'David S. Miller18-81/+432
Jakub Kicinski says: ==================== ethtool: rss: driver tweaks and netlink context dumps This series is a semi-related collection of RSS patches. Main point is supporting dumping RSS contexts via ethtool netlink. At present additional RSS contexts can be queried one by one, and assuming user know the right IDs. This series uses the XArray added by Ed to provide netlink dump support for ETHTOOL_GET_RSS. Patch 1 is a trivial selftest debug patch. Patch 2 coverts mvpp2 for no real reason other than that I had a grand plan of converting all drivers at some stage. Patch 3 removes a now moot check from mlx5 so that all tests can pass. Patch 4 and 5 make a bit used for context support optional, for easier grepping of drivers which need converting if nothing else. Patch 6 OTOH adds a new cap bit; some devices don't support using a different key per context and currently act in surprising ways. Patch 7 and 8 update the RSS netlink code to use XArray. Patch 9 and 10 add support for dumping contexts. Patch 11 and 12 are small adjustments to spec and a new test. I'm getting distracted with other work, so probably won't have the time soon to complete next steps, but things which are missing are (and some of these may be bad ideas): - better discovery Some sort of API to tell the user who many contexts the device can create. Upper bound, devices often share contexts between ports etc. so it's hard to tell exactly and upfront number of contexts for a netdev. But order of magnitude (4 vs 10s) may be enough for container management system to know whether to bother. - create/modify/delete via netlink The only question here is how to handle all the tricky IOCTL legacy. "No change" maps trivially to attribute not present. "reset" (indir_size = 0) probably needs to be a new NLA_FLAG? - better table size handling The current API assumes the LUT has fixed size, which isn't true for modern devices. We should have better APIs for the drivers to resize the tables, and in user facing API - the ability to specify pattern and min size rather than exact table expected (sort of like ethtool CLI already does). - recounted / socket-bound contexts Support for contexts which get "cleaned up" when their parent netlink socket gets closed. The major catch is that ntuple filters (which we don't currently track) depend on the context, so we need auto-removal for both. v5: - fix build v4: https://lore.kernel.org/[email protected] - adjust to the meaning of max context from net v3: https://lore.kernel.org/[email protected] - quite a few code comments and commit message changes - mvpp2: fix interpretation of max_context_id (I'll take care of the net -> net-next merge as needed) - filter by ifindex in the selftest v2: https://lore.kernel.org/[email protected] - fix bugs and build in mvpp2 v1: https://lore.kernel.org/[email protected] ==================== Signed-off-by: David S. Miller <[email protected]>
2024-08-12selftests: drv-net: rss_ctx: test dumping RSS contextsJakub Kicinski2-2/+80
Add a test for dumping RSS contexts. Make sure indir table and key are sane when contexts are created with various combination of inputs. Test the dump filtering by ifname and start-context. Reviewed-by: Petr Machata <[email protected]> Reviewed-by: Edward Cree <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12netlink: specs: decode indirection table as u32 arrayJakub Kicinski1-0/+1
Indirection table is dumped as a raw u32 array, decode it. It's tempting to decode hash key, too, but it is an actual bitstream, so leave it be for now. Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Donald Hunter <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12ethtool: rss: support skipping contexts during dumpJakub Kicinski5-4/+27
Applications may want to deal with dynamic RSS contexts only. So dumping context 0 will be counter-productive for them. Support starting the dump from a given context ID. Alternative would be to implement a dump flag to skip just context 0, not sure which is better... Reviewed-by: Edward Cree <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12ethtool: rss: support dumping RSS contextsJakub Kicinski4-2/+146
Now that we track RSS contexts in the core we can easily dump them. This is a major introspection improvement, as previously the only way to find all contexts would be to try all ids (of which there may be 2^32 - 1). Don't use the XArray iterators (like xa_for_each_start()) as they do not move the index past the end of the array once done, which caused multiple bugs in Netlink dumps in the past. Reviewed-by: Edward Cree <[email protected]> Reviewed-by: Joe Damato <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12ethtool: rss: report info about additional contexts from XArrayJakub Kicinski1-1/+36
IOCTL already uses the XArray when reporting info about additional contexts. Do the same thing in netlink code. Reviewed-by: Edward Cree <[email protected]> Reviewed-by: Joe Damato <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12ethtool: rss: move the device op invocation out of rss_prepare_data()Jakub Kicinski1-16/+27
Factor calling device ops out of rss_prepare_data(). Next patch will add alternative path using xarray. No functional changes. Reviewed-by: Joe Damato <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12ethtool: rss: don't report key if device doesn't support itJakub Kicinski8-10/+45
marvell/otx2 and mvpp2 do not support setting different keys for different RSS contexts. Contexts have separate indirection tables but key is shared with all other contexts. This is likely fine, indirection table is the most important piece. Don't report the key-related parameters from such drivers. This prevents driver-errors, e.g. otx2 always writes the main key, even when user asks to change per-context key. The second reason is that without this change tracking the keys by the core gets complicated. Even if the driver correctly reject setting key with rss_context != 0, change of the main key would have to be reflected in the XArray for all additional contexts. Since the additional contexts don't have their own keys not including the attributes (in Netlink speak) seems intuitive. ethtool CLI seems to deal with it just fine. Having to set the flag in majority of the drivers is a bit tedious but not reporting the key is a safer default. Reviewed-by: Edward Cree <[email protected]> Reviewed-by: Joe Damato <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12eth: remove .cap_rss_ctx_supported from updated driversJakub Kicinski4-4/+0
Remove .cap_rss_ctx_supported from drivers which moved to the new API. This makes it easy to grep for drivers which still need to be converted. Reviewed-by: Gal Pressman <[email protected]> Reviewed-by: Edward Cree <[email protected]> Reviewed-by: Joe Damato <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12ethtool: make ethtool_ops::cap_rss_ctx_supported optionalJakub Kicinski3-4/+8
cap_rss_ctx_supported was created because the API for creating and configuring additional contexts is mux'ed with the normal RSS API. Presence of ops does not imply driver can actually support rss_context != 0 (in fact drivers mostly ignore that field). cap_rss_ctx_supported lets core check that the driver is context-aware before calling it. Now that we have .create_rxfh_context, there is no such ambiguity. We can depend on presence of the op. Make setting the bit optional. Reviewed-by: Gal Pressman <[email protected]> Reviewed-by: Edward Cree <[email protected]> Reviewed-by: Joe Damato <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12eth: mlx5: allow disabling queues when RSS contexts existJakub Kicinski1-12/+0
Since commit 24ac7e544081 ("ethtool: use the rss context XArray in ring deactivation safety-check") core will prevent queues from being disabled while being used by additional RSS contexts. The safety check is no longer necessary, and core will do a more accurate job of only rejecting changes which can actually break things. Reviewed-by: Gal Pressman <[email protected]> Reviewed-by: Joe Damato <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12eth: mvpp2: implement new RSS context APIJakub Kicinski3-33/+69
Implement the separate create/modify/delete ops for RSS. No problems with IDs - even tho RSS tables are per device the driver already seems to allocate IDs linearly per port. There's a translation table from per-port context ID to device context ID. mvpp2 doesn't have a key for the hash, it defaults to an empty/previous indir table. Note that there is no key at all, so we don't have to be concerned with reporting the wrong one (which is addressed by a patch later in the series). Compile-tested only. Reviewed-by: Edward Cree <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12selftests: drv-net: rss_ctx: add identifier to traffic commentsJakub Kicinski1-2/+2
Include the "name" of the context in the comment for traffic checks. Makes it easier to reason about which context failed when we loop over 32 contexts (it may matter if we failed in first vs last, for example). Reviewed-by: Gal Pressman <[email protected]> Reviewed-by: Joe Damato <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12net: ethernet: mtk_wed: fix use-after-free panic in mtk_wed_setup_tc_block_cb()Zheng Zhang1-2/+4
When there are multiple ap interfaces on one band and with WED on, turning the interface down will cause a kernel panic on MT798X. Previously, cb_priv was freed in mtk_wed_setup_tc_block() without marking NULL,and mtk_wed_setup_tc_block_cb() didn't check the value, too. Assign NULL after free cb_priv in mtk_wed_setup_tc_block() and check NULL in mtk_wed_setup_tc_block_cb(). ---------- Unable to handle kernel paging request at virtual address 0072460bca32b4f5 Call trace: mtk_wed_setup_tc_block_cb+0x4/0x38 0xffffffc0794084bc tcf_block_playback_offloads+0x70/0x1e8 tcf_block_unbind+0x6c/0xc8 ... --------- Fixes: 799684448e3e ("net: ethernet: mtk_wed: introduce wed wo support") Signed-off-by: Zheng Zhang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12drm/connector: kerneldoc: Fix two missing newlines in drm_connector.cDaniel Yang1-0/+4
Fix the unexpected indentation errors. drm_connector.c has some kerneldoc comments that were missing newlines. This results in the following warnings when running make htmldocs: ./Documentation/gpu/drm-kms:538: ./drivers/gpu/drm/drm_connector.c:2344: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils] ./Documentation/gpu/drm-kms:538: ./drivers/gpu/drm/drm_connector.c:2346: ERROR: Unexpected indentation. [docutils] ./Documentation/gpu/drm-kms:538: ./drivers/gpu/drm/drm_connector.c:2368: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils] ./Documentation/gpu/drm-kms:538: ./drivers/gpu/drm/drm_connector.c:2381: ERROR: Unexpected indentation. [docutils] Signed-off-by: Daniel Yang <[email protected]> Reviewed-by: Shuah Khan <[email protected]> [hmahfooz: append drm/connector prefix] Signed-off-by: Hamza Mahfooz <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-12ata: ahci_imx: Correct the email addressRichard Zhu1-1/+1
Correct the email address of driver author. Signed-off-by: Richard Zhu <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Cassel <[email protected]>
2024-08-12ata: ahci_imx: Enlarge RX water mark for i.MX8QM SATARichard Zhu1-0/+10
The RXWM(RxWaterMark) sets the minimum number of free location within the RX FIFO before the watermark is exceeded which in turn will cause the Transport Layer to instruct the Link Layer to transmit HOLDS to the transmitting end. Based on the default RXWM value 0x20, RX FIFO overflow might be observed on i.MX8QM MEK board, when some Gen3 SATA disks are used. The FIFO overflow will result in CRC error, internal error and protocol error, then the SATA link is not stable anymore. To fix this issue, enlarge RX water mark setting from 0x20 to 0x29. Signed-off-by: Richard Zhu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Cassel <[email protected]>
2024-08-12ata: ahci_imx: AHB clock rate setting is not required on i.MX8QM AHCI SATARichard Zhu1-13/+15
i.MX8QM AHCI SATA doesn't need set AHB clock rate to config the vendor specified TIMER1MS register. Set AHB clock rate only for i.MX53 and i.MX6Q. Signed-off-by: Richard Zhu <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Cassel <[email protected]>
2024-08-12ata: ahci_imx: Clean up code by using i.MX8Q HSIO PHY driverRichard Zhu1-285/+80
Clean up code by using PHY interface provided by the PHY driver under PHY subsystem(drivers/phy/freescale/phy-fsl-imx8qm-hsio.c). Signed-off-by: Richard Zhu <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Cassel <[email protected]>
2024-08-12dt-bindings: ata: Add i.MX8QM AHCI compatible stringRichard Zhu1-0/+47
Add i.MX8QM AHCI "fsl,imx8qm-ahci" compatible strings. i.MX8QM AHCI SATA doesn't require AHB clock rate to set the vendor specified TIMER1MS register. ahb clock is not required by i.MX8QM AHCI. Update the description of clocks in the dt-binding accordingly. Signed-off-by: Richard Zhu <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Cassel <[email protected]>
2024-08-12net: vxlan: remove duplicated initialization in vxlan_xmitMenglong Dong1-1/+1
The variable "did_rsc" is initialized twice, which is unnecessary. Just remove one of them. Signed-off-by: Menglong Dong <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12net: mana: Fix RX buf alloc_size alignment and atomic op panicHaiyang Zhang1-1/+5
The MANA driver's RX buffer alloc_size is passed into napi_build_skb() to create SKB. skb_shinfo(skb) is located at the end of skb, and its alignment is affected by the alloc_size passed into napi_build_skb(). The size needs to be aligned properly for better performance and atomic operations. Otherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic operations may panic on the skb_shinfo(skb)->dataref due to alignment fault. To fix this bug, add proper alignment to the alloc_size calculation. Sample panic info: [ 253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce [ 253.300900] Mem abort info: [ 253.301760] ESR = 0x0000000096000021 [ 253.302825] EC = 0x25: DABT (current EL), IL = 32 bits [ 253.304268] SET = 0, FnV = 0 [ 253.305172] EA = 0, S1PTW = 0 [ 253.306103] FSC = 0x21: alignment fault Call trace: __skb_clone+0xfc/0x198 skb_clone+0x78/0xe0 raw6_local_deliver+0xfc/0x228 ip6_protocol_deliver_rcu+0x80/0x500 ip6_input_finish+0x48/0x80 ip6_input+0x48/0xc0 ip6_sublist_rcv_finish+0x50/0x78 ip6_sublist_rcv+0x1cc/0x2b8 ipv6_list_rcv+0x100/0x150 __netif_receive_skb_list_core+0x180/0x220 netif_receive_skb_list_internal+0x198/0x2a8 __napi_poll+0x138/0x250 net_rx_action+0x148/0x330 handle_softirqs+0x12c/0x3a0 Cc: [email protected] Fixes: 80f6215b450e ("net: mana: Add support for jumbo frame") Signed-off-by: Haiyang Zhang <[email protected]> Reviewed-by: Long Li <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12net: sunvnet: use ethtool_sprintf/putsRosen Penev1-24/+10
Simpler and allows avoiding manual pointer addition. Signed-off-by: Rosen Penev <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12dt-bindings: net: fsl,qoriq-mc-dpmac: add missed property physFrank Li1-0/+4
Add missed property phys, which indicate how connect to serdes phy. Fix below warning: arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dtb: fsl-mc@80c000000: dpmacs:ethernet@7: Unevaluated properties are not allowed ('phys' was unexpected) Signed-off-by: Frank Li <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12Merge drm/drm-next into drm-misc-nextThomas Zimmermann10989-166835/+516009
Get drm-misc-next to the state of v6.11-rc2. Signed-off-by: Thomas Zimmermann <[email protected]>
2024-08-12powerpc/mm: Fix boot warning with hugepages and CONFIG_DEBUG_VIRTUALChristophe Leroy2-2/+1
Booting with CONFIG_DEBUG_VIRTUAL leads to following warning when passing hugepage reservation on command line: Kernel command line: hugepagesz=1g hugepages=1 hugepagesz=64m hugepages=1 hugepagesz=256m hugepages=1 noreboot HugeTLB: allocating 1 of page size 1.00 GiB failed. Only allocated 0 hugepages. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at arch/powerpc/include/asm/io.h:948 __alloc_bootmem_huge_page+0xd4/0x284 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 6.10.0-rc6-00396-g6b0e82791bd0-dirty #936 Hardware name: MPC8544DS e500v2 0x80210030 MPC8544 DS NIP: c1020240 LR: c10201d0 CTR: 00000000 REGS: c13fdd30 TRAP: 0700 Not tainted (6.10.0-rc6-00396-g6b0e82791bd0-dirty) MSR: 00021000 <CE,ME> CR: 44084288 XER: 20000000 GPR00: c10201d0 c13fde20 c130b560 e8000000 e8001000 00000000 00000000 c1420000 GPR08: 00000000 00028001 00000000 00000004 44084282 01066ac0 c0eb7c9c efffe149 GPR16: c0fc4228 0000005f ffffffff c0eb7d0c c0eb7cc0 c0eb7ce0 ffffffff 00000000 GPR24: c1441cec efffe153 e8001000 c14240c0 00000000 c1441d64 00000000 e8000000 NIP [c1020240] __alloc_bootmem_huge_page+0xd4/0x284 LR [c10201d0] __alloc_bootmem_huge_page+0x64/0x284 Call Trace: [c13fde20] [c10201d0] __alloc_bootmem_huge_page+0x64/0x284 (unreliable) [c13fde50] [c10207b8] hugetlb_hstate_alloc_pages+0x8c/0x3e8 [c13fdeb0] [c1021384] hugepages_setup+0x240/0x2cc [c13fdef0] [c1000574] unknown_bootoption+0xfc/0x280 [c13fdf30] [c0078904] parse_args+0x200/0x4c4 [c13fdfa0] [c1000d9c] start_kernel+0x238/0x7d0 [c13fdff0] [c0000434] set_ivor+0x12c/0x168 Code: 554aa33e 7c042840 3ce0c142 80a7427c 5109a016 50caa016 7c9a2378 7fdcf378 4180000c 7c052040 41810160 7c095040 <0fe00000> 38c00000 40800108 3c60c0eb ---[ end trace 0000000000000000 ]--- This is due to virt_addr_valid() using high_memory before it is set. high_memory is set in mem_init() using max_low_pfn, but max_low_pfn is available long before, it is set in mem_topology_setup(). So just like commit daa9ada2093e ("powerpc/mm: Fix boot crash with FLATMEM") moved the setting of max_mapnr immediately after the call to mem_topology_setup(), the same can be done for high_memory. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/62b69c4baad067093f39e7e60df0fe27a86b8d2a.1723100702.git.christophe.leroy@csgroup.eu
2024-08-12powerpc/mm: Fix size of allocated PGDIRChristophe Leroy1-2/+2
Commit 6b0e82791bd0 ("powerpc/e500: switch to 64 bits PGD on 85xx (32 bits)") increased the size of PGD entries but failed to increase the PGD directory. Use the size of pgd_t instead of the size of pointers to calculate the allocated size. Reported-by: Guenter Roeck <[email protected]> Fixes: 6b0e82791bd0 ("powerpc/e500: switch to 64 bits PGD on 85xx (32 bits)") Signed-off-by: Christophe Leroy <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/1cdaacb391cbd3e0240f0e0faf691202874e9422.1723109462.git.christophe.leroy@csgroup.eu
2024-08-12ARM: dts: imx6dl-yapp43: Increase LED current to match the yapp4 HW designMichal Vokáč1-6/+6
On the imx6dl-yapp4 revision based boards, the RGB LED is not driven directly by the LP5562 driver but through FET transistors. Hence the LED current is not determined by the driver but by the LED series resistors. On the imx6dl-yapp43 revision based boards, we removed the FET transistors to drive the LED directly from the LP5562 but forgot to tune the output current to match the previous HW design. Set the LED current on imx6dl-yapp43 based boards to the same values measured on the imx6dl-yapp4 boards and limit the maximum current to 20mA. Fixes: 7da4734751e0 ("ARM: dts: imx6dl-yapp43: Add support for new HW revision of the IOTA board") Cc: <[email protected]> Signed-off-by: Michal Vokáč <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-12arm64: dts: imx8mm-tqma8mqml-mba8mx: Increase frequency for i2c bussesAlexander Stein2-3/+5
100kHz is only needed for the USB Hub TUSB8041. But as this device is not connected by default, the speed can be increased. The other busses don't have any 100kHz only devices attached. Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-12ARM: dts: imx53-qsb-hdmi: Merge display0 nodeLiu Ying1-2/+0
It's not necessary to split display0 node. Merge it to save two lines. Signed-off-by: Liu Ying <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-12ARM: dts: imx53-qsb-hdmi: Do not disable TVELiu Ying1-4/+0
SII9022 and TVE are connected with IPU DI0 and IPU DI1 respectively, so they are in two different display pipelines and may run simultaneously. Keep TVE being enabled as imx53-qsb-common.dtsi does by not setting it's status property to "disabled". Fixes: eeb403df953f ("ARM: dts: imx53-qsb: add support for the HDMI expander") Signed-off-by: Liu Ying <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-12arm64: dts: imx8-ss-dma: Fix adc0 closing brace locationAlexander Stein1-1/+1
Align the closing brace to opening line. Fixes: 1db044b25d2e ("arm64: dts: imx8dxl: add adc0 support") Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-12arm64: dts: imx8-ss-dma: add #address-cells and #size-cells to LPI2C nodesAlexander Stein1-0/+8
These properties are required by i2c-controller.yaml bindings. Add them on SoC level, rather than on board level. Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-08-12Merge branch 'vsc73xx-fix-mdio-and-phy'David S. Miller2-27/+41
Pawel Dembicki says: ==================== net: dsa: vsc73xx: fix MDIO bus access and PHY opera This series are extracted patches from net-next series [0]. The VSC73xx driver has issues with PHY configuration. This patch series fixes most of them. The first patch synchronizes the register configuration routine with the datasheet recommendations. Patches 2-3 restore proper communication on the MDIO bus. Currently, the write value isn't sent to the MDIO register, and without a busy check, communication with the PHY can be interrupted. This causes the PHY to receive improper configuration and autonegotiation could fail. The fourth patch removes the PHY reset blockade, as it is no longer required. After fixing the MDIO operations, autonegotiation became possible. The last patch removes the blockade, which became unnecessary after the MDIO operations fix. [0] https://patchwork.kernel.org/project/netdevbpf/list/?series=874739&state=%2A&archive=both ==================== Signed-off-by: David S. Miller <[email protected]>
2024-08-12net: phy: vitesse: repair vsc73xx autonegotiationPawel Dembicki1-14/+0
When the vsc73xx mdio bus work properly, the generic autonegotiation configuration works well. Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Pawel Dembicki <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12net: dsa: vsc73xx: allow phy resettingPawel Dembicki1-11/+0
Resetting the VSC73xx PHY was problematic because the MDIO bus, without a busy check, read and wrote incorrect register values. My investigation indicates that resetting the PHY only triggers changes in configuration. However, improper register values written earlier were only exposed after a soft reset. The reset itself wasn't the issue; rather, the problem stemmed from incorrect read and write operations. A 'soft_reset' can now proceed normally. There are no reasons to keep the VSC73xx from being reset. This commit removes the reset blockade in the 'vsc73xx_phy_write' function. Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Pawel Dembicki <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12net: dsa: vsc73xx: check busy flag in MDIO operationsPawel Dembicki1-1/+36
The VSC73xx has a busy flag used during MDIO operations. It is raised when MDIO read/write operations are in progress. Without it, PHYs are misconfigured and bus operations do not work as expected. Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver") Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Pawel Dembicki <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12net: dsa: vsc73xx: pass value in phy_write operationPawel Dembicki1-1/+1
In the 'vsc73xx_phy_write' function, the register value is missing, and the phy write operation always sends zeros. This commit passes the value variable into the proper register. Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver") Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Pawel Dembicki <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12net: dsa: vsc73xx: fix port MAC configuration in full duplex modePawel Dembicki1-1/+5
According to the datasheet description ("Port Mode Procedure" in 5.6.2), the VSC73XX_MAC_CFG_WEXC_DIS bit is configured only for half duplex mode. The WEXC_DIS bit is responsible for MAC behavior after an excessive collision. Let's set it as described in the datasheet. Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver") Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Pawel Dembicki <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-12media: rkisp1: Cache the currently active formatJacopo Mondi2-22/+38
The rkisp1-params driver assumes the data buffer format is the only currently supported "fixed" one. The usage of the "fixed" format is assumed when allocating memory for the scratch buffers and when initializing the vb2 queue. In order to prepare to support the "extensible" format beside the existing "fixed" one, add support in the driver for both formats by caching a pointer to the active one in the driver structure and use it in the vb2 queue operations and subdev pad operations implementations. Do not yet allow userspace to select between the two formats as the support for the "extensible" format parsing will be introduced in a later patch in the series. While at it, document the un-documented ycbcr_encoding field of struct rkisp1_params_ops. Signed-off-by: Jacopo Mondi <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Paul Elder <[email protected]> Tested-by: Kieran Bingham <[email protected]> Acked-by: Sakari Ailus <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]>
2024-08-12media: rkisp1: Copy the parameters bufferJacopo Mondi2-31/+60
The ISP parameters buffers are queued by userspace to the params video device and appended by the driver to the list of available buffers for later consumption. As the parameters buffer is mapped in the userspace process memory, applications have access to the buffer content after the buffer has been queued. To prevent userspace from modifying the contents of the parameters buffer after it has been queued to the video device, add to 'struct rkisp1_params_buffer' a scratch buffer where to copy the parameters. Allocate the scratch buffer in the vb2 buf_init() operation and copy the buffer content in the buf_prepare() operation. Free the scratch buffer in the newly introduced buf_cleanup() operation handler. Modify the ISP configuration function to access the ISP configuration from the cached copy of the parameters buffer instead of using the userspace-mapped one. Signed-off-by: Jacopo Mondi <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Paul Elder <[email protected]> Tested-by: Kieran Bingham <[email protected]> Acked-by: Sakari Ailus <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]>