mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-12-27 12:21:22 -05:00
Merge tag 'v6.15' into rdma.git for-next
Following patches need the RDMA rc branch since we are past the RC cycle now. Merge conflicts resolved based on Linux-next: - For RXE odp changes keep for-next version and fixup new places that need to call is_odp_mr() https://lore.kernel.org/r/20250422143019.500201bd@canb.auug.org.au https://lore.kernel.org/r/20250514122455.3593b083@canb.auug.org.au - irdma is keeping the while/kfree bugfix from -rc and the pf/cdev_info change from for-next https://lore.kernel.org/r/20250513130630.280ee6c5@canb.auug.org.au Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
This commit is contained in:
Jason Gunthorpe
@@ -92,6 +92,7 @@ ForEachMacros:
|
||||
- '__rq_for_each_bio'
|
||||
- '__shost_for_each_device'
|
||||
- '__sym_for_each'
|
||||
- '_for_each_counter'
|
||||
- 'apei_estatus_for_each_section'
|
||||
- 'ata_for_each_dev'
|
||||
- 'ata_for_each_link'
|
||||
@@ -141,11 +142,14 @@ ForEachMacros:
|
||||
- 'damon_for_each_target_safe'
|
||||
- 'damos_for_each_filter'
|
||||
- 'damos_for_each_filter_safe'
|
||||
- 'damos_for_each_ops_filter'
|
||||
- 'damos_for_each_ops_filter_safe'
|
||||
- 'damos_for_each_quota_goal'
|
||||
- 'damos_for_each_quota_goal_safe'
|
||||
- 'data__for_each_file'
|
||||
- 'data__for_each_file_new'
|
||||
- 'data__for_each_file_start'
|
||||
- 'def_for_each_cpu'
|
||||
- 'device_for_each_child_node'
|
||||
- 'device_for_each_child_node_scoped'
|
||||
- 'dma_fence_array_for_each'
|
||||
@@ -176,6 +180,7 @@ ForEachMacros:
|
||||
- 'drm_for_each_privobj'
|
||||
- 'drm_gem_for_each_gpuvm_bo'
|
||||
- 'drm_gem_for_each_gpuvm_bo_safe'
|
||||
- 'drm_gpusvm_for_each_range'
|
||||
- 'drm_gpuva_for_each_op'
|
||||
- 'drm_gpuva_for_each_op_from_reverse'
|
||||
- 'drm_gpuva_for_each_op_reverse'
|
||||
@@ -216,8 +221,10 @@ ForEachMacros:
|
||||
- 'for_each_active_dev_scope'
|
||||
- 'for_each_active_drhd_unit'
|
||||
- 'for_each_active_iommu'
|
||||
- 'for_each_active_irq'
|
||||
- 'for_each_active_route'
|
||||
- 'for_each_aggr_pgid'
|
||||
- 'for_each_alloc_capable_rdt_resource'
|
||||
- 'for_each_and_bit'
|
||||
- 'for_each_andnot_bit'
|
||||
- 'for_each_available_child_of_node'
|
||||
@@ -228,6 +235,7 @@ ForEachMacros:
|
||||
- 'for_each_btf_ext_rec'
|
||||
- 'for_each_btf_ext_sec'
|
||||
- 'for_each_bvec'
|
||||
- 'for_each_capable_rdt_resource'
|
||||
- 'for_each_card_auxs'
|
||||
- 'for_each_card_auxs_safe'
|
||||
- 'for_each_card_components'
|
||||
@@ -241,6 +249,7 @@ ForEachMacros:
|
||||
- 'for_each_cgroup_storage_type'
|
||||
- 'for_each_child_of_node'
|
||||
- 'for_each_child_of_node_scoped'
|
||||
- 'for_each_child_of_node_with_prefix'
|
||||
- 'for_each_clear_bit'
|
||||
- 'for_each_clear_bit_from'
|
||||
- 'for_each_clear_bitrange'
|
||||
@@ -296,6 +305,7 @@ ForEachMacros:
|
||||
- 'for_each_group_member_head'
|
||||
- 'for_each_hstate'
|
||||
- 'for_each_hwgpio'
|
||||
- 'for_each_hwgpio_in_range'
|
||||
- 'for_each_if'
|
||||
- 'for_each_inject_fn'
|
||||
- 'for_each_insn'
|
||||
@@ -304,6 +314,7 @@ ForEachMacros:
|
||||
- 'for_each_intid'
|
||||
- 'for_each_iommu'
|
||||
- 'for_each_ip_tunnel_rcu'
|
||||
- 'for_each_irq_desc'
|
||||
- 'for_each_irq_nr'
|
||||
- 'for_each_lang'
|
||||
- 'for_each_link_ch_maps'
|
||||
@@ -324,6 +335,8 @@ ForEachMacros:
|
||||
- 'for_each_missing_reg'
|
||||
- 'for_each_mle_subelement'
|
||||
- 'for_each_mod_mem_type'
|
||||
- 'for_each_mon_capable_rdt_resource'
|
||||
- 'for_each_mp_bvec'
|
||||
- 'for_each_net'
|
||||
- 'for_each_net_continue_reverse'
|
||||
- 'for_each_net_rcu'
|
||||
@@ -351,6 +364,7 @@ ForEachMacros:
|
||||
- 'for_each_node_by_name'
|
||||
- 'for_each_node_by_type'
|
||||
- 'for_each_node_mask'
|
||||
- 'for_each_node_numadist'
|
||||
- 'for_each_node_state'
|
||||
- 'for_each_node_with_cpus'
|
||||
- 'for_each_node_with_property'
|
||||
@@ -359,6 +373,8 @@ ForEachMacros:
|
||||
- 'for_each_of_allnodes'
|
||||
- 'for_each_of_allnodes_from'
|
||||
- 'for_each_of_cpu_node'
|
||||
- 'for_each_of_graph_port'
|
||||
- 'for_each_of_graph_port_endpoint'
|
||||
- 'for_each_of_pci_range'
|
||||
- 'for_each_old_connector_in_state'
|
||||
- 'for_each_old_crtc_in_state'
|
||||
@@ -372,9 +388,11 @@ ForEachMacros:
|
||||
- 'for_each_oldnew_plane_in_state_reverse'
|
||||
- 'for_each_oldnew_private_obj_in_state'
|
||||
- 'for_each_online_cpu'
|
||||
- 'for_each_online_cpu_wrap'
|
||||
- 'for_each_online_node'
|
||||
- 'for_each_online_pgdat'
|
||||
- 'for_each_or_bit'
|
||||
- 'for_each_page_ext'
|
||||
- 'for_each_path'
|
||||
- 'for_each_pci_bridge'
|
||||
- 'for_each_pci_dev'
|
||||
@@ -382,8 +400,10 @@ ForEachMacros:
|
||||
- 'for_each_physmem_range'
|
||||
- 'for_each_populated_zone'
|
||||
- 'for_each_possible_cpu'
|
||||
- 'for_each_possible_cpu_wrap'
|
||||
- 'for_each_present_blessed_reg'
|
||||
- 'for_each_present_cpu'
|
||||
- 'for_each_present_section_nr'
|
||||
- 'for_each_prime_number'
|
||||
- 'for_each_prime_number_from'
|
||||
- 'for_each_probe_cache_entry'
|
||||
@@ -396,6 +416,7 @@ ForEachMacros:
|
||||
- 'for_each_prop_dlc_cpus'
|
||||
- 'for_each_prop_dlc_platforms'
|
||||
- 'for_each_property_of_node'
|
||||
- 'for_each_rdt_resource'
|
||||
- 'for_each_reg'
|
||||
- 'for_each_reg_filtered'
|
||||
- 'for_each_reloc'
|
||||
@@ -434,10 +455,10 @@ ForEachMacros:
|
||||
- 'for_each_subelement_id'
|
||||
- 'for_each_sublist'
|
||||
- 'for_each_subsystem'
|
||||
- 'for_each_suite'
|
||||
- 'for_each_supported_activate_fn'
|
||||
- 'for_each_supported_inject_fn'
|
||||
- 'for_each_sym'
|
||||
- 'for_each_test'
|
||||
- 'for_each_thread'
|
||||
- 'for_each_token'
|
||||
- 'for_each_unicast_dest_pgid'
|
||||
@@ -499,8 +520,10 @@ ForEachMacros:
|
||||
- 'idr_for_each_entry_continue'
|
||||
- 'idr_for_each_entry_continue_ul'
|
||||
- 'idr_for_each_entry_ul'
|
||||
- 'iio_for_each_active_channel'
|
||||
- 'in_dev_for_each_ifa_rcu'
|
||||
- 'in_dev_for_each_ifa_rtnl'
|
||||
- 'in_dev_for_each_ifa_rtnl_net'
|
||||
- 'inet_bind_bucket_for_each'
|
||||
- 'interval_tree_for_each_span'
|
||||
- 'intlist__for_each_entry'
|
||||
@@ -542,7 +565,6 @@ ForEachMacros:
|
||||
- 'list_for_each_prev'
|
||||
- 'list_for_each_prev_safe'
|
||||
- 'list_for_each_rcu'
|
||||
- 'list_for_each_reverse'
|
||||
- 'list_for_each_safe'
|
||||
- 'llist_for_each'
|
||||
- 'llist_for_each_entry'
|
||||
@@ -552,6 +574,7 @@ ForEachMacros:
|
||||
- 'map__for_each_symbol'
|
||||
- 'map__for_each_symbol_by_name'
|
||||
- 'mas_for_each'
|
||||
- 'mas_for_each_rev'
|
||||
- 'mci_for_each_dimm'
|
||||
- 'media_device_for_each_entity'
|
||||
- 'media_device_for_each_intf'
|
||||
@@ -561,10 +584,15 @@ ForEachMacros:
|
||||
- 'media_pipeline_for_each_entity'
|
||||
- 'media_pipeline_for_each_pad'
|
||||
- 'mlx5_lag_for_each_peer_mdev'
|
||||
- 'mptcp_for_each_subflow'
|
||||
- 'msi_domain_for_each_desc'
|
||||
- 'msi_for_each_desc'
|
||||
- 'mt_for_each'
|
||||
- 'nanddev_io_for_each_block'
|
||||
- 'nanddev_io_for_each_page'
|
||||
- 'neigh_for_each_in_bucket'
|
||||
- 'neigh_for_each_in_bucket_rcu'
|
||||
- 'neigh_for_each_in_bucket_safe'
|
||||
- 'netdev_for_each_lower_dev'
|
||||
- 'netdev_for_each_lower_private'
|
||||
- 'netdev_for_each_lower_private_rcu'
|
||||
@@ -604,11 +632,11 @@ ForEachMacros:
|
||||
- 'perf_evlist__for_each_entry_safe'
|
||||
- 'perf_evlist__for_each_evsel'
|
||||
- 'perf_evlist__for_each_mmap'
|
||||
- 'perf_evsel_for_each_per_thread_period_safe'
|
||||
- 'perf_hpp_list__for_each_format'
|
||||
- 'perf_hpp_list__for_each_format_safe'
|
||||
- 'perf_hpp_list__for_each_sort_list'
|
||||
- 'perf_hpp_list__for_each_sort_list_safe'
|
||||
- 'perf_tool_event__for_each_event'
|
||||
- 'plist_for_each'
|
||||
- 'plist_for_each_continue'
|
||||
- 'plist_for_each_entry'
|
||||
@@ -627,7 +655,6 @@ ForEachMacros:
|
||||
- 'rdma_for_each_block'
|
||||
- 'rdma_for_each_port'
|
||||
- 'rdma_umem_for_each_dma_block'
|
||||
- 'resort_rb__for_each_entry'
|
||||
- 'resource_list_for_each_entry'
|
||||
- 'resource_list_for_each_entry_safe'
|
||||
- 'rhl_for_each_entry_rcu'
|
||||
@@ -658,6 +685,7 @@ ForEachMacros:
|
||||
- 'shost_for_each_device'
|
||||
- 'sk_for_each'
|
||||
- 'sk_for_each_bound'
|
||||
- 'sk_for_each_bound_safe'
|
||||
- 'sk_for_each_entry_offset_rcu'
|
||||
- 'sk_for_each_from'
|
||||
- 'sk_for_each_rcu'
|
||||
@@ -680,7 +708,11 @@ ForEachMacros:
|
||||
- 'tb_property_for_each'
|
||||
- 'tcf_act_for_each_action'
|
||||
- 'tcf_exts_for_each_action'
|
||||
- 'test_suite__for_each_test_case'
|
||||
- 'tool_pmu__for_each_event'
|
||||
- 'ttm_bo_lru_for_each_reserved_guarded'
|
||||
- 'ttm_resource_manager_for_each_res'
|
||||
- 'udp_lrpa_for_each_entry_rcu'
|
||||
- 'udp_portaddr_for_each_entry'
|
||||
- 'udp_portaddr_for_each_entry_rcu'
|
||||
- 'usb_hub_for_each_child'
|
||||
@@ -691,6 +723,7 @@ ForEachMacros:
|
||||
- 'v4l2_m2m_for_each_src_buf_safe'
|
||||
- 'virtio_device_for_each_vq'
|
||||
- 'while_for_each_ftrace_op'
|
||||
- 'workloads__for_each'
|
||||
- 'xa_for_each'
|
||||
- 'xa_for_each_marked'
|
||||
- 'xa_for_each_range'
|
||||
|
||||
@@ -7,5 +7,5 @@ check-private-items = true
|
||||
disallowed-macros = [
|
||||
# The `clippy::dbg_macro` lint only works with `std::dbg!`, thus we simulate
|
||||
# it here, see: https://github.com/rust-lang/rust-clippy/issues/11303.
|
||||
{ path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool" },
|
||||
{ path = "kernel::dbg", reason = "the `dbg!` macro is intended as a debugging tool", allow-invalid = true },
|
||||
]
|
||||
|
||||
11
.mailmap
11
.mailmap
@@ -102,6 +102,7 @@ Ard Biesheuvel <ardb@kernel.org> <ard.biesheuvel@linaro.org>
|
||||
Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Arun Kumar Neelakantam <quic_aneela@quicinc.com> <aneela@codeaurora.org>
|
||||
Asahi Lina <lina+kernel@asahilina.net> <lina@asahilina.net>
|
||||
Ashok Raj Nagarajan <quic_arnagara@quicinc.com> <arnagara@codeaurora.org>
|
||||
Ashwin Chaugule <quic_ashwinc@quicinc.com> <ashwinc@codeaurora.org>
|
||||
Asutosh Das <quic_asutoshd@quicinc.com> <asutoshd@codeaurora.org>
|
||||
@@ -312,6 +313,7 @@ Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
|
||||
Jan Kuliga <jtkuliga.kdev@gmail.com> <jankul@alatek.krakow.pl>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@linux.intel.com>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@opinsys.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
|
||||
@@ -322,6 +324,7 @@ Jayachandran C <c.jayachandran@gmail.com> <jchandra@broadcom.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jchandra@digeo.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jnair@caviumnetworks.com>
|
||||
<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
|
||||
Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org> <jeanmichel.hautbois@ideasonboard.com>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
Jeevan Shriram <quic_jshriram@quicinc.com> <jshriram@codeaurora.org>
|
||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
@@ -438,12 +441,16 @@ Linus Lüssing <linus.luessing@c0d3.blue> <ll@simonwunderlich.de>
|
||||
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
|
||||
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
|
||||
Lior David <quic_liord@quicinc.com> <liord@codeaurora.org>
|
||||
Loic Poulain <loic.poulain@oss.qualcomm.com> <loic.poulain@linaro.org>
|
||||
Loic Poulain <loic.poulain@oss.qualcomm.com> <loic.poulain@intel.com>
|
||||
Lorenzo Pieralisi <lpieralisi@kernel.org> <lorenzo.pieralisi@arm.com>
|
||||
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> <lstoakes@gmail.com>
|
||||
Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
|
||||
Luca Weiss <luca@lucaweiss.eu> <luca@z3ntu.xyz>
|
||||
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
|
||||
Luo Jie <quic_luoj@quicinc.com> <luoj@codeaurora.org>
|
||||
Lance Yang <lance.yang@linux.dev> <ioworker0@gmail.com>
|
||||
Lance Yang <lance.yang@linux.dev> <mingzhe.yang@ly.com>
|
||||
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
|
||||
Maciej W. Rozycki <macro@orcam.me.uk> <macro@linux-mips.org>
|
||||
Maharaja Kennadyrajan <quic_mkenna@quicinc.com> <mkenna@codeaurora.org>
|
||||
@@ -480,6 +487,7 @@ Matthias Fuchs <socketcan@esd.eu> <matthias.fuchs@esd.eu>
|
||||
Matthieu Baerts <matttbe@kernel.org> <matthieu.baerts@tessares.net>
|
||||
Matthieu CASTET <castet.matthieu@free.fr>
|
||||
Matti Vaittinen <mazziesaccount@gmail.com> <matti.vaittinen@fi.rohmeurope.com>
|
||||
Mattijs Korpershoek <mkorpershoek@kernel.org> <mkorpershoek@baylibre.com>
|
||||
Matt Ranostay <matt@ranostay.sg> <matt.ranostay@konsulko.com>
|
||||
Matt Ranostay <matt@ranostay.sg> <matt@ranostay.consulting>
|
||||
Matt Ranostay <matt@ranostay.sg> Matthew Ranostay <mranostay@embeddedalley.com>
|
||||
@@ -685,6 +693,8 @@ Simon Wunderlich <sw@simonwunderlich.de> <simon.wunderlich@saxnet.de>
|
||||
Simon Wunderlich <sw@simonwunderlich.de> <simon@open-mesh.com>
|
||||
Simon Wunderlich <sw@simonwunderlich.de> <siwu@hrz.tu-chemnitz.de>
|
||||
Sricharan Ramabadhran <quic_srichara@quicinc.com> <sricharan@codeaurora.org>
|
||||
Srinivas Kandagatla <srini@kernel.org> <srinivas.kandagatla@st.com>
|
||||
Srinivas Kandagatla <srini@kernel.org> <srinivas.kandagatla@linaro.org>
|
||||
Srinivas Ramana <quic_sramana@quicinc.com> <sramana@codeaurora.org>
|
||||
Sriram R <quic_srirrama@quicinc.com> <srirrama@codeaurora.org>
|
||||
Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> <sriram.yagnaraman@est.tech>
|
||||
@@ -744,6 +754,7 @@ Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko@ursulin.net>
|
||||
Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>
|
||||
Tzung-Bi Shih <tzungbi@kernel.org> <tzungbi@google.com>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Uwe Kleine-König <u.kleine-koenig@baylibre.com> <ukleinek@baylibre.com>
|
||||
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Uwe Kleine-König <ukleinek@strlen.de>
|
||||
Uwe Kleine-König <ukl@pengutronix.de>
|
||||
|
||||
4
CREDITS
4
CREDITS
@@ -2071,6 +2071,10 @@ S: 660 Harvard Ave. #7
|
||||
S: Santa Clara, CA 95051
|
||||
S: USA
|
||||
|
||||
N: Joonsoo Kim
|
||||
E: iamjoonsoo.kim@lge.com
|
||||
D: Slab allocators
|
||||
|
||||
N: Kukjin Kim
|
||||
E: kgene@kernel.org
|
||||
D: Samsung S3C, S5P and Exynos ARM architectures
|
||||
|
||||
@@ -77,7 +77,7 @@ Description:
|
||||
|
||||
What: /sys/block/<disk>/diskseq
|
||||
Date: February 2021
|
||||
Contact: Matteo Croce <mcroce@microsoft.com>
|
||||
Contact: Matteo Croce <teknoraver@meta.com>
|
||||
Description:
|
||||
The /sys/block/<disk>/diskseq files reports the disk
|
||||
sequence number, which is a monotonically increasing
|
||||
|
||||
@@ -511,6 +511,7 @@ Description: information about CPUs heterogeneity.
|
||||
|
||||
What: /sys/devices/system/cpu/vulnerabilities
|
||||
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
|
||||
/sys/devices/system/cpu/vulnerabilities/indirect_target_selection
|
||||
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
|
||||
/sys/devices/system/cpu/vulnerabilities/l1tf
|
||||
/sys/devices/system/cpu/vulnerabilities/mds
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
What: /sys/bus/hid/drivers/hid-appletb-kbd/<dev>/mode
|
||||
Date: September, 2023
|
||||
KernelVersion: 6.5
|
||||
Date: March, 2025
|
||||
KernelVersion: 6.15
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
The set of keys displayed on the Touch Bar.
|
||||
|
||||
@@ -111,7 +111,7 @@ Description: RO. Package current voltage in millivolt.
|
||||
|
||||
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp2_input
|
||||
Date: March 2025
|
||||
KernelVersion: 6.14
|
||||
KernelVersion: 6.15
|
||||
Contact: intel-xe@lists.freedesktop.org
|
||||
Description: RO. Package temperature in millidegree Celsius.
|
||||
|
||||
@@ -119,7 +119,7 @@ Description: RO. Package temperature in millidegree Celsius.
|
||||
|
||||
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp3_input
|
||||
Date: March 2025
|
||||
KernelVersion: 6.14
|
||||
KernelVersion: 6.15
|
||||
Contact: intel-xe@lists.freedesktop.org
|
||||
Description: RO. VRAM temperature in millidegree Celsius.
|
||||
|
||||
|
||||
@@ -1604,3 +1604,35 @@ Description:
|
||||
prevent the UFS from frequently performing clock gating/ungating.
|
||||
|
||||
The attribute is read/write.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_lvl_exception_count
|
||||
What: /sys/bus/platform/devices/*.ufs/device_lvl_exception_count
|
||||
Date: March 2025
|
||||
Contact: Bao D. Nguyen <quic_nguyenb@quicinc.com>
|
||||
Description:
|
||||
This attribute is applicable to ufs devices compliant to the
|
||||
JEDEC specifications version 4.1 or later. The
|
||||
device_lvl_exception_count is a counter indicating the number of
|
||||
times the device level exceptions have occurred since the last
|
||||
time this variable is reset. Writing a 0 value to this
|
||||
attribute will reset the device_lvl_exception_count. If the
|
||||
device_lvl_exception_count reads a positive value, the user
|
||||
application should read the device_lvl_exception_id attribute to
|
||||
know more information about the exception.
|
||||
|
||||
The attribute is read/write.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_lvl_exception_id
|
||||
What: /sys/bus/platform/devices/*.ufs/device_lvl_exception_id
|
||||
Date: March 2025
|
||||
Contact: Bao D. Nguyen <quic_nguyenb@quicinc.com>
|
||||
Description:
|
||||
Reading the device_lvl_exception_id returns the
|
||||
qDeviceLevelExceptionID attribute of the ufs device JEDEC
|
||||
specification version 4.1. The definition of the
|
||||
qDeviceLevelExceptionID is the ufs device vendor specific
|
||||
implementation. Refer to the device manufacturer datasheet for
|
||||
more information on the meaning of the qDeviceLevelExceptionID
|
||||
attribute value.
|
||||
|
||||
The attribute is read only.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
What: /sys/kernel/reboot
|
||||
Date: November 2020
|
||||
KernelVersion: 5.11
|
||||
Contact: Matteo Croce <mcroce@microsoft.com>
|
||||
Contact: Matteo Croce <teknoraver@meta.com>
|
||||
Description: Interface to set the kernel reboot behavior, similarly to
|
||||
what can be done via the reboot= cmdline option.
|
||||
(see Documentation/admin-guide/kernel-parameters.txt)
|
||||
@@ -9,25 +9,25 @@ Description: Interface to set the kernel reboot behavior, similarly to
|
||||
What: /sys/kernel/reboot/mode
|
||||
Date: November 2020
|
||||
KernelVersion: 5.11
|
||||
Contact: Matteo Croce <mcroce@microsoft.com>
|
||||
Contact: Matteo Croce <teknoraver@meta.com>
|
||||
Description: Reboot mode. Valid values are: cold warm hard soft gpio
|
||||
|
||||
What: /sys/kernel/reboot/type
|
||||
Date: November 2020
|
||||
KernelVersion: 5.11
|
||||
Contact: Matteo Croce <mcroce@microsoft.com>
|
||||
Contact: Matteo Croce <teknoraver@meta.com>
|
||||
Description: Reboot type. Valid values are: bios acpi kbd triple efi pci
|
||||
|
||||
What: /sys/kernel/reboot/cpu
|
||||
Date: November 2020
|
||||
KernelVersion: 5.11
|
||||
Contact: Matteo Croce <mcroce@microsoft.com>
|
||||
Contact: Matteo Croce <teknoraver@meta.com>
|
||||
Description: CPU number to use to reboot.
|
||||
|
||||
What: /sys/kernel/reboot/force
|
||||
Date: November 2020
|
||||
KernelVersion: 5.11
|
||||
Contact: Matteo Croce <mcroce@microsoft.com>
|
||||
Contact: Matteo Croce <teknoraver@meta.com>
|
||||
Description: Don't wait for any other CPUs on reboot and
|
||||
avoid anything that could hang.
|
||||
|
||||
|
||||
@@ -22,3 +22,5 @@ are configurable at compile, boot or run time.
|
||||
srso
|
||||
gather_data_sampling
|
||||
reg-file-data-sampling
|
||||
rsb
|
||||
indirect-target-selection
|
||||
|
||||
168
Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
Normal file
168
Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
Normal file
@@ -0,0 +1,168 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Indirect Target Selection (ITS)
|
||||
===============================
|
||||
|
||||
ITS is a vulnerability in some Intel CPUs that support Enhanced IBRS and were
|
||||
released before Alder Lake. ITS may allow an attacker to control the prediction
|
||||
of indirect branches and RETs located in the lower half of a cacheline.
|
||||
|
||||
ITS is assigned CVE-2024-28956 with a CVSS score of 4.7 (Medium).
|
||||
|
||||
Scope of Impact
|
||||
---------------
|
||||
- **eIBRS Guest/Host Isolation**: Indirect branches in KVM/kernel may still be
|
||||
predicted with unintended target corresponding to a branch in the guest.
|
||||
|
||||
- **Intra-Mode BTI**: In-kernel training such as through cBPF or other native
|
||||
gadgets.
|
||||
|
||||
- **Indirect Branch Prediction Barrier (IBPB)**: After an IBPB, indirect
|
||||
branches may still be predicted with targets corresponding to direct branches
|
||||
executed prior to the IBPB. This is fixed by the IPU 2025.1 microcode, which
|
||||
should be available via distro updates. Alternatively microcode can be
|
||||
obtained from Intel's github repository [#f1]_.
|
||||
|
||||
Affected CPUs
|
||||
-------------
|
||||
Below is the list of ITS affected CPUs [#f2]_ [#f3]_:
|
||||
|
||||
======================== ============ ==================== ===============
|
||||
Common name Family_Model eIBRS Intra-mode BTI
|
||||
Guest/Host Isolation
|
||||
======================== ============ ==================== ===============
|
||||
SKYLAKE_X (step >= 6) 06_55H Affected Affected
|
||||
ICELAKE_X 06_6AH Not affected Affected
|
||||
ICELAKE_D 06_6CH Not affected Affected
|
||||
ICELAKE_L 06_7EH Not affected Affected
|
||||
TIGERLAKE_L 06_8CH Not affected Affected
|
||||
TIGERLAKE 06_8DH Not affected Affected
|
||||
KABYLAKE_L (step >= 12) 06_8EH Affected Affected
|
||||
KABYLAKE (step >= 13) 06_9EH Affected Affected
|
||||
COMETLAKE 06_A5H Affected Affected
|
||||
COMETLAKE_L 06_A6H Affected Affected
|
||||
ROCKETLAKE 06_A7H Not affected Affected
|
||||
======================== ============ ==================== ===============
|
||||
|
||||
- All affected CPUs enumerate Enhanced IBRS feature.
|
||||
- IBPB isolation is affected on all ITS affected CPUs, and need a microcode
|
||||
update for mitigation.
|
||||
- None of the affected CPUs enumerate BHI_CTRL which was introduced in Golden
|
||||
Cove (Alder Lake and Sapphire Rapids). This can help guests to determine the
|
||||
host's affected status.
|
||||
- Intel Atom CPUs are not affected by ITS.
|
||||
|
||||
Mitigation
|
||||
----------
|
||||
As only the indirect branches and RETs that have their last byte of instruction
|
||||
in the lower half of the cacheline are vulnerable to ITS, the basic idea behind
|
||||
the mitigation is to not allow indirect branches in the lower half.
|
||||
|
||||
This is achieved by relying on existing retpoline support in the kernel, and in
|
||||
compilers. ITS-vulnerable retpoline sites are runtime patched to point to newly
|
||||
added ITS-safe thunks. These safe thunks consists of indirect branch in the
|
||||
second half of the cacheline. Not all retpoline sites are patched to thunks, if
|
||||
a retpoline site is evaluated to be ITS-safe, it is replaced with an inline
|
||||
indirect branch.
|
||||
|
||||
Dynamic thunks
|
||||
~~~~~~~~~~~~~~
|
||||
From a dynamically allocated pool of safe-thunks, each vulnerable site is
|
||||
replaced with a new thunk, such that they get a unique address. This could
|
||||
improve the branch prediction accuracy. Also, it is a defense-in-depth measure
|
||||
against aliasing.
|
||||
|
||||
Note, for simplicity, indirect branches in eBPF programs are always replaced
|
||||
with a jump to a static thunk in __x86_indirect_its_thunk_array. If required,
|
||||
in future this can be changed to use dynamic thunks.
|
||||
|
||||
All vulnerable RETs are replaced with a static thunk, they do not use dynamic
|
||||
thunks. This is because RETs get their prediction from RSB mostly that does not
|
||||
depend on source address. RETs that underflow RSB may benefit from dynamic
|
||||
thunks. But, RETs significantly outnumber indirect branches, and any benefit
|
||||
from a unique source address could be outweighed by the increased icache
|
||||
footprint and iTLB pressure.
|
||||
|
||||
Retpoline
|
||||
~~~~~~~~~
|
||||
Retpoline sequence also mitigates ITS-unsafe indirect branches. For this
|
||||
reason, when retpoline is enabled, ITS mitigation only relocates the RETs to
|
||||
safe thunks. Unless user requested the RSB-stuffing mitigation.
|
||||
|
||||
RSB Stuffing
|
||||
~~~~~~~~~~~~
|
||||
RSB-stuffing via Call Depth Tracking is a mitigation for Retbleed RSB-underflow
|
||||
attacks. And it also mitigates RETs that are vulnerable to ITS.
|
||||
|
||||
Mitigation in guests
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
All guests deploy ITS mitigation by default, irrespective of eIBRS enumeration
|
||||
and Family/Model of the guest. This is because eIBRS feature could be hidden
|
||||
from a guest. One exception to this is when a guest enumerates BHI_DIS_S, which
|
||||
indicates that the guest is running on an unaffected host.
|
||||
|
||||
To prevent guests from unnecessarily deploying the mitigation on unaffected
|
||||
platforms, Intel has defined ITS_NO bit(62) in MSR IA32_ARCH_CAPABILITIES. When
|
||||
a guest sees this bit set, it should not enumerate the ITS bug. Note, this bit
|
||||
is not set by any hardware, but is **intended for VMMs to synthesize** it for
|
||||
guests as per the host's affected status.
|
||||
|
||||
Mitigation options
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
The ITS mitigation can be controlled using the "indirect_target_selection"
|
||||
kernel parameter. The available options are:
|
||||
|
||||
======== ===================================================================
|
||||
on (default) Deploy the "Aligned branch/return thunks" mitigation.
|
||||
If spectre_v2 mitigation enables retpoline, aligned-thunks are only
|
||||
deployed for the affected RET instructions. Retpoline mitigates
|
||||
indirect branches.
|
||||
|
||||
off Disable ITS mitigation.
|
||||
|
||||
vmexit Equivalent to "=on" if the CPU is affected by guest/host isolation
|
||||
part of ITS. Otherwise, mitigation is not deployed. This option is
|
||||
useful when host userspace is not in the threat model, and only
|
||||
attacks from guest to host are considered.
|
||||
|
||||
stuff Deploy RSB-fill mitigation when retpoline is also deployed.
|
||||
Otherwise, deploy the default mitigation. When retpoline mitigation
|
||||
is enabled, RSB-stuffing via Call-Depth-Tracking also mitigates
|
||||
ITS.
|
||||
|
||||
force Force the ITS bug and deploy the default mitigation.
|
||||
======== ===================================================================
|
||||
|
||||
Sysfs reporting
|
||||
---------------
|
||||
|
||||
The sysfs file showing ITS mitigation status is:
|
||||
|
||||
/sys/devices/system/cpu/vulnerabilities/indirect_target_selection
|
||||
|
||||
Note, microcode mitigation status is not reported in this file.
|
||||
|
||||
The possible values in this file are:
|
||||
|
||||
.. list-table::
|
||||
|
||||
* - Not affected
|
||||
- The processor is not vulnerable.
|
||||
* - Vulnerable
|
||||
- System is vulnerable and no mitigation has been applied.
|
||||
* - Vulnerable, KVM: Not affected
|
||||
- System is vulnerable to intra-mode BTI, but not affected by eIBRS
|
||||
guest/host isolation.
|
||||
* - Mitigation: Aligned branch/return thunks
|
||||
- The mitigation is enabled, affected indirect branches and RETs are
|
||||
relocated to safe thunks.
|
||||
* - Mitigation: Retpolines, Stuffing RSB
|
||||
- The mitigation is enabled using retpoline and RSB stuffing.
|
||||
|
||||
References
|
||||
----------
|
||||
.. [#f1] Microcode repository - https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
|
||||
|
||||
.. [#f2] Affected Processors list - https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
|
||||
|
||||
.. [#f3] Affected Processors list (machine readable) - https://github.com/intel/Intel-affected-processor-list
|
||||
268
Documentation/admin-guide/hw-vuln/rsb.rst
Normal file
268
Documentation/admin-guide/hw-vuln/rsb.rst
Normal file
@@ -0,0 +1,268 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=======================
|
||||
RSB-related mitigations
|
||||
=======================
|
||||
|
||||
.. warning::
|
||||
Please keep this document up-to-date, otherwise you will be
|
||||
volunteered to update it and convert it to a very long comment in
|
||||
bugs.c!
|
||||
|
||||
Since 2018 there have been many Spectre CVEs related to the Return Stack
|
||||
Buffer (RSB) (sometimes referred to as the Return Address Stack (RAS) or
|
||||
Return Address Predictor (RAP) on AMD).
|
||||
|
||||
Information about these CVEs and how to mitigate them is scattered
|
||||
amongst a myriad of microarchitecture-specific documents.
|
||||
|
||||
This document attempts to consolidate all the relevant information in
|
||||
once place and clarify the reasoning behind the current RSB-related
|
||||
mitigations. It's meant to be as concise as possible, focused only on
|
||||
the current kernel mitigations: what are the RSB-related attack vectors
|
||||
and how are they currently being mitigated?
|
||||
|
||||
It's *not* meant to describe how the RSB mechanism operates or how the
|
||||
exploits work. More details about those can be found in the references
|
||||
below.
|
||||
|
||||
Rather, this is basically a glorified comment, but too long to actually
|
||||
be one. So when the next CVE comes along, a kernel developer can
|
||||
quickly refer to this as a refresher to see what we're actually doing
|
||||
and why.
|
||||
|
||||
At a high level, there are two classes of RSB attacks: RSB poisoning
|
||||
(Intel and AMD) and RSB underflow (Intel only). They must each be
|
||||
considered individually for each attack vector (and microarchitecture
|
||||
where applicable).
|
||||
|
||||
----
|
||||
|
||||
RSB poisoning (Intel and AMD)
|
||||
=============================
|
||||
|
||||
SpectreRSB
|
||||
~~~~~~~~~~
|
||||
|
||||
RSB poisoning is a technique used by SpectreRSB [#spectre-rsb]_ where
|
||||
an attacker poisons an RSB entry to cause a victim's return instruction
|
||||
to speculate to an attacker-controlled address. This can happen when
|
||||
there are unbalanced CALLs/RETs after a context switch or VMEXIT.
|
||||
|
||||
* All attack vectors can potentially be mitigated by flushing out any
|
||||
poisoned RSB entries using an RSB filling sequence
|
||||
[#intel-rsb-filling]_ [#amd-rsb-filling]_ when transitioning between
|
||||
untrusted and trusted domains. But this has a performance impact and
|
||||
should be avoided whenever possible.
|
||||
|
||||
.. DANGER::
|
||||
**FIXME**: Currently we're flushing 32 entries. However, some CPU
|
||||
models have more than 32 entries. The loop count needs to be
|
||||
increased for those. More detailed information is needed about RSB
|
||||
sizes.
|
||||
|
||||
* On context switch, the user->user mitigation requires ensuring the
|
||||
RSB gets filled or cleared whenever IBPB gets written [#cond-ibpb]_
|
||||
during a context switch:
|
||||
|
||||
* AMD:
|
||||
On Zen 4+, IBPB (or SBPB [#amd-sbpb]_ if used) clears the RSB.
|
||||
This is indicated by IBPB_RET in CPUID [#amd-ibpb-rsb]_.
|
||||
|
||||
On Zen < 4, the RSB filling sequence [#amd-rsb-filling]_ must be
|
||||
always be done in addition to IBPB [#amd-ibpb-no-rsb]_. This is
|
||||
indicated by X86_BUG_IBPB_NO_RET.
|
||||
|
||||
* Intel:
|
||||
IBPB always clears the RSB:
|
||||
|
||||
"Software that executed before the IBPB command cannot control
|
||||
the predicted targets of indirect branches executed after the
|
||||
command on the same logical processor. The term indirect branch
|
||||
in this context includes near return instructions, so these
|
||||
predicted targets may come from the RSB." [#intel-ibpb-rsb]_
|
||||
|
||||
* On context switch, user->kernel attacks are prevented by SMEP. User
|
||||
space can only insert user space addresses into the RSB. Even
|
||||
non-canonical addresses can't be inserted due to the page gap at the
|
||||
end of the user canonical address space reserved by TASK_SIZE_MAX.
|
||||
A SMEP #PF at instruction fetch prevents the kernel from speculatively
|
||||
executing user space.
|
||||
|
||||
* AMD:
|
||||
"Finally, branches that are predicted as 'ret' instructions get
|
||||
their predicted targets from the Return Address Predictor (RAP).
|
||||
AMD recommends software use a RAP stuffing sequence (mitigation
|
||||
V2-3 in [2]) and/or Supervisor Mode Execution Protection (SMEP)
|
||||
to ensure that the addresses in the RAP are safe for
|
||||
speculation. Collectively, we refer to these mitigations as "RAP
|
||||
Protection"." [#amd-smep-rsb]_
|
||||
|
||||
* Intel:
|
||||
"On processors with enhanced IBRS, an RSB overwrite sequence may
|
||||
not suffice to prevent the predicted target of a near return
|
||||
from using an RSB entry created in a less privileged predictor
|
||||
mode. Software can prevent this by enabling SMEP (for
|
||||
transitions from user mode to supervisor mode) and by having
|
||||
IA32_SPEC_CTRL.IBRS set during VM exits." [#intel-smep-rsb]_
|
||||
|
||||
* On VMEXIT, guest->host attacks are mitigated by eIBRS (and PBRSB
|
||||
mitigation if needed):
|
||||
|
||||
* AMD:
|
||||
"When Automatic IBRS is enabled, the internal return address
|
||||
stack used for return address predictions is cleared on VMEXIT."
|
||||
[#amd-eibrs-vmexit]_
|
||||
|
||||
* Intel:
|
||||
"On processors with enhanced IBRS, an RSB overwrite sequence may
|
||||
not suffice to prevent the predicted target of a near return
|
||||
from using an RSB entry created in a less privileged predictor
|
||||
mode. Software can prevent this by enabling SMEP (for
|
||||
transitions from user mode to supervisor mode) and by having
|
||||
IA32_SPEC_CTRL.IBRS set during VM exits. Processors with
|
||||
enhanced IBRS still support the usage model where IBRS is set
|
||||
only in the OS/VMM for OSes that enable SMEP. To do this, such
|
||||
processors will ensure that guest behavior cannot control the
|
||||
RSB after a VM exit once IBRS is set, even if IBRS was not set
|
||||
at the time of the VM exit." [#intel-eibrs-vmexit]_
|
||||
|
||||
Note that some Intel CPUs are susceptible to Post-barrier Return
|
||||
Stack Buffer Predictions (PBRSB) [#intel-pbrsb]_, where the last
|
||||
CALL from the guest can be used to predict the first unbalanced RET.
|
||||
In this case the PBRSB mitigation is needed in addition to eIBRS.
|
||||
|
||||
AMD RETBleed / SRSO / Branch Type Confusion
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
On AMD, poisoned RSB entries can also be created by the AMD RETBleed
|
||||
variant [#retbleed-paper]_ [#amd-btc]_ or by Speculative Return Stack
|
||||
Overflow [#amd-srso]_ (Inception [#inception-paper]_). The kernel
|
||||
protects itself by replacing every RET in the kernel with a branch to a
|
||||
single safe RET.
|
||||
|
||||
----
|
||||
|
||||
RSB underflow (Intel only)
|
||||
==========================
|
||||
|
||||
RSB Alternate (RSBA) ("Intel Retbleed")
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some Intel Skylake-generation CPUs are susceptible to the Intel variant
|
||||
of RETBleed [#retbleed-paper]_ (Return Stack Buffer Underflow
|
||||
[#intel-rsbu]_). If a RET is executed when the RSB buffer is empty due
|
||||
to mismatched CALLs/RETs or returning from a deep call stack, the branch
|
||||
predictor can fall back to using the Branch Target Buffer (BTB). If a
|
||||
user forces a BTB collision then the RET can speculatively branch to a
|
||||
user-controlled address.
|
||||
|
||||
* Note that RSB filling doesn't fully mitigate this issue. If there
|
||||
are enough unbalanced RETs, the RSB may still underflow and fall back
|
||||
to using a poisoned BTB entry.
|
||||
|
||||
* On context switch, user->user underflow attacks are mitigated by the
|
||||
conditional IBPB [#cond-ibpb]_ on context switch which effectively
|
||||
clears the BTB:
|
||||
|
||||
* "The indirect branch predictor barrier (IBPB) is an indirect branch
|
||||
control mechanism that establishes a barrier, preventing software
|
||||
that executed before the barrier from controlling the predicted
|
||||
targets of indirect branches executed after the barrier on the same
|
||||
logical processor." [#intel-ibpb-btb]_
|
||||
|
||||
* On context switch and VMEXIT, user->kernel and guest->host RSB
|
||||
underflows are mitigated by IBRS or eIBRS:
|
||||
|
||||
* "Enabling IBRS (including enhanced IBRS) will mitigate the "RSBU"
|
||||
attack demonstrated by the researchers. As previously documented,
|
||||
Intel recommends the use of enhanced IBRS, where supported. This
|
||||
includes any processor that enumerates RRSBA but not RRSBA_DIS_S."
|
||||
[#intel-rsbu]_
|
||||
|
||||
However, note that eIBRS and IBRS do not mitigate intra-mode attacks.
|
||||
Like RRSBA below, this is mitigated by clearing the BHB on kernel
|
||||
entry.
|
||||
|
||||
As an alternative to classic IBRS, call depth tracking (combined with
|
||||
retpolines) can be used to track kernel returns and fill the RSB when
|
||||
it gets close to being empty.
|
||||
|
||||
Restricted RSB Alternate (RRSBA)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Some newer Intel CPUs have Restricted RSB Alternate (RRSBA) behavior,
|
||||
which, similar to RSBA described above, also falls back to using the BTB
|
||||
on RSB underflow. The only difference is that the predicted targets are
|
||||
restricted to the current domain when eIBRS is enabled:
|
||||
|
||||
* "Restricted RSB Alternate (RRSBA) behavior allows alternate branch
|
||||
predictors to be used by near RET instructions when the RSB is
|
||||
empty. When eIBRS is enabled, the predicted targets of these
|
||||
alternate predictors are restricted to those belonging to the
|
||||
indirect branch predictor entries of the current prediction domain.
|
||||
[#intel-eibrs-rrsba]_
|
||||
|
||||
When a CPU with RRSBA is vulnerable to Branch History Injection
|
||||
[#bhi-paper]_ [#intel-bhi]_, an RSB underflow could be used for an
|
||||
intra-mode BTI attack. This is mitigated by clearing the BHB on
|
||||
kernel entry.
|
||||
|
||||
However if the kernel uses retpolines instead of eIBRS, it needs to
|
||||
disable RRSBA:
|
||||
|
||||
* "Where software is using retpoline as a mitigation for BHI or
|
||||
intra-mode BTI, and the processor both enumerates RRSBA and
|
||||
enumerates RRSBA_DIS controls, it should disable this behavior."
|
||||
[#intel-retpoline-rrsba]_
|
||||
|
||||
----
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#spectre-rsb] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://arxiv.org/pdf/1807.07940.pdf>`_
|
||||
|
||||
.. [#intel-rsb-filling] "Empty RSB Mitigation on Skylake-generation" in `Retpoline: A Branch Target Injection Mitigation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html#inpage-nav-5-1>`_
|
||||
|
||||
.. [#amd-rsb-filling] "Mitigation V2-3" in `Software Techniques for Managing Speculation <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/software-techniques-for-managing-speculation.pdf>`_
|
||||
|
||||
.. [#cond-ibpb] Whether IBPB is written depends on whether the prev and/or next task is protected from Spectre attacks. It typically requires opting in per task or system-wide. For more details see the documentation for the ``spectre_v2_user`` cmdline option in Documentation/admin-guide/kernel-parameters.txt.
|
||||
|
||||
.. [#amd-sbpb] IBPB without flushing of branch type predictions. Only exists for AMD.
|
||||
|
||||
.. [#amd-ibpb-rsb] "Function 8000_0008h -- Processor Capacity Parameters and Extended Feature Identification" in `AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf>`_. SBPB behaves the same way according to `this email <https://lore.kernel.org/5175b163a3736ca5fd01cedf406735636c99a>`_.
|
||||
|
||||
.. [#amd-ibpb-no-rsb] `Spectre Attacks: Exploiting Speculative Execution <https://comsec.ethz.ch/wp-content/files/ibpb_sp25.pdf>`_
|
||||
|
||||
.. [#intel-ibpb-rsb] "Introduction" in `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_
|
||||
|
||||
.. [#amd-smep-rsb] "Existing Mitigations" in `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_
|
||||
|
||||
.. [#intel-smep-rsb] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_
|
||||
|
||||
.. [#amd-eibrs-vmexit] "Extended Feature Enable Register (EFER)" in `AMD64 Architecture Programmer's Manual Volume 2: System Programming <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf>`_
|
||||
|
||||
.. [#intel-eibrs-vmexit] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_
|
||||
|
||||
.. [#intel-pbrsb] `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_
|
||||
|
||||
.. [#retbleed-paper] `RETBleed: Arbitrary Speculative Code Execution with Return Instruction <https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf>`_
|
||||
|
||||
.. [#amd-btc] `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_
|
||||
|
||||
.. [#amd-srso] `Technical Update Regarding Speculative Return Stack Overflow <https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf>`_
|
||||
|
||||
.. [#inception-paper] `Inception: Exposing New Attack Surfaces with Training in Transient Execution <https://comsec.ethz.ch/wp-content/files/inception_sec23.pdf>`_
|
||||
|
||||
.. [#intel-rsbu] `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_
|
||||
|
||||
.. [#intel-ibpb-btb] `Indirect Branch Predictor Barrier' <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-predictor-barrier.html>`_
|
||||
|
||||
.. [#intel-eibrs-rrsba] "Guidance for RSBU" in `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_
|
||||
|
||||
.. [#bhi-paper] `Branch History Injection: On the Effectiveness of Hardware Mitigations Against Cross-Privilege Spectre-v2 Attacks <http://download.vusec.net/papers/bhi-spectre-bhb_sec22.pdf>`_
|
||||
|
||||
.. [#intel-bhi] `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_
|
||||
|
||||
.. [#intel-retpoline-rrsba] "Retpoline" in `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_
|
||||
@@ -1407,18 +1407,15 @@
|
||||
earlyprintk=serial[,0x...[,baudrate]]
|
||||
earlyprintk=ttySn[,baudrate]
|
||||
earlyprintk=dbgp[debugController#]
|
||||
earlyprintk=mmio32,membase[,{nocfg|baudrate}]
|
||||
earlyprintk=pciserial[,force],bus:device.function[,{nocfg|baudrate}]
|
||||
earlyprintk=xdbc[xhciController#]
|
||||
earlyprintk=bios
|
||||
earlyprintk=mmio,membase[,{nocfg|baudrate}]
|
||||
|
||||
earlyprintk is useful when the kernel crashes before
|
||||
the normal console is initialized. It is not enabled by
|
||||
default because it has some cosmetic problems.
|
||||
|
||||
Only 32-bit memory addresses are supported for "mmio"
|
||||
and "pciserial" devices.
|
||||
|
||||
Use "nocfg" to skip UART configuration, assume
|
||||
BIOS/firmware has configured UART correctly.
|
||||
|
||||
@@ -2205,6 +2202,23 @@
|
||||
different crypto accelerators. This option can be used
|
||||
to achieve best performance for particular HW.
|
||||
|
||||
indirect_target_selection= [X86,Intel] Mitigation control for Indirect
|
||||
Target Selection(ITS) bug in Intel CPUs. Updated
|
||||
microcode is also required for a fix in IBPB.
|
||||
|
||||
on: Enable mitigation (default).
|
||||
off: Disable mitigation.
|
||||
force: Force the ITS bug and deploy default
|
||||
mitigation.
|
||||
vmexit: Only deploy mitigation if CPU is affected by
|
||||
guest/host isolation part of ITS.
|
||||
stuff: Deploy RSB-fill mitigation when retpoline is
|
||||
also deployed. Otherwise, deploy the default
|
||||
mitigation.
|
||||
|
||||
For details see:
|
||||
Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
|
||||
|
||||
init= [KNL]
|
||||
Format: <full_path>
|
||||
Run specified binary instead of /sbin/init as init
|
||||
@@ -3696,6 +3710,7 @@
|
||||
expose users to several CPU vulnerabilities.
|
||||
Equivalent to: if nokaslr then kpti=0 [ARM64]
|
||||
gather_data_sampling=off [X86]
|
||||
indirect_target_selection=off [X86]
|
||||
kvm.nx_huge_pages=off [X86]
|
||||
l1tf=off [X86]
|
||||
mds=off [X86]
|
||||
|
||||
@@ -124,6 +124,14 @@ When mounting an XFS filesystem, the following options are accepted.
|
||||
controls the size of each buffer and so is also relevant to
|
||||
this case.
|
||||
|
||||
lifetime (default) or nolifetime
|
||||
Enable data placement based on write life time hints provided
|
||||
by the user. This turns on co-allocation of data of similar
|
||||
life times when statistically favorable to reduce garbage
|
||||
collection cost.
|
||||
|
||||
These options are only available for zoned rt file systems.
|
||||
|
||||
logbsize=value
|
||||
Set the size of each in-memory log buffer. The size may be
|
||||
specified in bytes, or in kilobytes with a "k" suffix.
|
||||
@@ -143,6 +151,14 @@ When mounting an XFS filesystem, the following options are accepted.
|
||||
optional, and the log section can be separate from the data
|
||||
section or contained within it.
|
||||
|
||||
max_open_zones=value
|
||||
Specify the max number of zones to keep open for writing on a
|
||||
zoned rt device. Many open zones aids file data separation
|
||||
but may impact performance on HDDs.
|
||||
|
||||
If ``max_open_zones`` is not specified, the value is determined
|
||||
by the capabilities and the size of the zoned rt device.
|
||||
|
||||
noalign
|
||||
Data allocations will not be aligned at stripe unit
|
||||
boundaries. This is only relevant to filesystems created
|
||||
@@ -542,3 +558,24 @@ The interesting knobs for XFS workqueues are as follows:
|
||||
nice Relative priority of scheduling the threads. These are the
|
||||
same nice levels that can be applied to userspace processes.
|
||||
============ ===========
|
||||
|
||||
Zoned Filesystems
|
||||
=================
|
||||
|
||||
For zoned file systems, the following attributes are exposed in:
|
||||
|
||||
/sys/fs/xfs/<dev>/zoned/
|
||||
|
||||
max_open_zones (Min: 1 Default: Varies Max: UINTMAX)
|
||||
This read-only attribute exposes the maximum number of open zones
|
||||
available for data placement. The value is determined at mount time and
|
||||
is limited by the capabilities of the backing zoned device, file system
|
||||
size and the max_open_zones mount option.
|
||||
|
||||
zonegc_low_space (Min: 0 Default: 0 Max: 100)
|
||||
Define a percentage for how much of the unused space that GC should keep
|
||||
available for writing. A high value will reclaim more of the space
|
||||
occupied by unused blocks, creating a larger buffer against write
|
||||
bursts at the cost of increased write amplification. Regardless
|
||||
of this value, garbage collection will always aim to free a minimum
|
||||
amount of blocks to keep max_open_zones open for data placement purposes.
|
||||
|
||||
@@ -7,10 +7,10 @@ target architecture, specifically, is the 32-bit OpenRISC 1000 family (or1k).
|
||||
|
||||
For information about OpenRISC processors and ongoing development:
|
||||
|
||||
======= =============================
|
||||
======= ==============================
|
||||
website https://openrisc.io
|
||||
email openrisc@lists.librecores.org
|
||||
======= =============================
|
||||
email linux-openrisc@vger.kernel.org
|
||||
======= ==============================
|
||||
|
||||
---------------------------------------------------------------------
|
||||
|
||||
@@ -27,11 +27,11 @@ Toolchain binaries can be obtained from openrisc.io or our github releases page.
|
||||
Instructions for building the different toolchains can be found on openrisc.io
|
||||
or Stafford's toolchain build and release scripts.
|
||||
|
||||
========== =================================================
|
||||
binaries https://github.com/openrisc/or1k-gcc/releases
|
||||
========== ==========================================================
|
||||
binaries https://github.com/stffrdhrn/or1k-toolchain-build/releases
|
||||
toolchains https://openrisc.io/software
|
||||
building https://github.com/stffrdhrn/or1k-toolchain-build
|
||||
========== =================================================
|
||||
========== ==========================================================
|
||||
|
||||
2) Building
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ The following keys are defined:
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_MARCHID`: Contains the value of ``marchid``, as
|
||||
defined by the RISC-V privileged architecture specification.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_MIMPLID`: Contains the value of ``mimplid``, as
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_MIMPID`: Contains the value of ``mimpid``, as
|
||||
defined by the RISC-V privileged architecture specification.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_BASE_BEHAVIOR`: A bitmask containing the base
|
||||
|
||||
@@ -79,8 +79,9 @@ feature flags.
|
||||
How are feature flags created?
|
||||
==============================
|
||||
|
||||
a: Feature flags can be derived from the contents of CPUID leaves.
|
||||
------------------------------------------------------------------
|
||||
Feature flags can be derived from the contents of CPUID leaves
|
||||
--------------------------------------------------------------
|
||||
|
||||
These feature definitions are organized mirroring the layout of CPUID
|
||||
leaves and grouped in words with offsets as mapped in enum cpuid_leafs
|
||||
in cpufeatures.h (see arch/x86/include/asm/cpufeatures.h for details).
|
||||
@@ -89,8 +90,9 @@ cpufeatures.h, and if it is detected at run time, the flags will be
|
||||
displayed accordingly in /proc/cpuinfo. For example, the flag "avx2"
|
||||
comes from X86_FEATURE_AVX2 in cpufeatures.h.
|
||||
|
||||
b: Flags can be from scattered CPUID-based features.
|
||||
----------------------------------------------------
|
||||
Flags can be from scattered CPUID-based features
|
||||
------------------------------------------------
|
||||
|
||||
Hardware features enumerated in sparsely populated CPUID leaves get
|
||||
software-defined values. Still, CPUID needs to be queried to determine
|
||||
if a given feature is present. This is done in init_scattered_cpuid_features().
|
||||
@@ -104,8 +106,9 @@ has only one feature and would waste 31 bits of space in the x86_capability[]
|
||||
array. Since there is a struct cpuinfo_x86 for each possible CPU, the wasted
|
||||
memory is not trivial.
|
||||
|
||||
c: Flags can be created synthetically under certain conditions for hardware features.
|
||||
-------------------------------------------------------------------------------------
|
||||
Flags can be created synthetically under certain conditions for hardware features
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
Examples of conditions include whether certain features are present in
|
||||
MSR_IA32_CORE_CAPS or specific CPU models are identified. If the needed
|
||||
conditions are met, the features are enabled by the set_cpu_cap or
|
||||
@@ -114,8 +117,8 @@ the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and
|
||||
"split_lock_detect" will be displayed. The flag "ring3mwait" will be
|
||||
displayed only when running on INTEL_XEON_PHI_[KNL|KNM] processors.
|
||||
|
||||
d: Flags can represent purely software features.
|
||||
------------------------------------------------
|
||||
Flags can represent purely software features
|
||||
--------------------------------------------
|
||||
These flags do not represent hardware features. Instead, they represent a
|
||||
software feature implemented in the kernel. For example, Kernel Page Table
|
||||
Isolation is purely software feature and its feature flag X86_FEATURE_PTI is
|
||||
@@ -130,14 +133,18 @@ x86_cap/bug_flags[] arrays in kernel/cpu/capflags.c. The names in the
|
||||
resulting x86_cap/bug_flags[] are used to populate /proc/cpuinfo. The naming
|
||||
of flags in the x86_cap/bug_flags[] are as follows:
|
||||
|
||||
a: The name of the flag is from the string in X86_FEATURE_<name> by default.
|
||||
----------------------------------------------------------------------------
|
||||
By default, the flag <name> in /proc/cpuinfo is extracted from the respective
|
||||
X86_FEATURE_<name> in cpufeatures.h. For example, the flag "avx2" is from
|
||||
X86_FEATURE_AVX2.
|
||||
Flags do not appear by default in /proc/cpuinfo
|
||||
-----------------------------------------------
|
||||
|
||||
Feature flags are omitted by default from /proc/cpuinfo as it does not make
|
||||
sense for the feature to be exposed to userspace in most cases. For example,
|
||||
X86_FEATURE_ALWAYS is defined in cpufeatures.h but that flag is an internal
|
||||
kernel feature used in the alternative runtime patching functionality. So the
|
||||
flag does not appear in /proc/cpuinfo.
|
||||
|
||||
Specify a flag name if absolutely needed
|
||||
----------------------------------------
|
||||
|
||||
b: The naming can be overridden.
|
||||
--------------------------------
|
||||
If the comment on the line for the #define X86_FEATURE_* starts with a
|
||||
double-quote character (""), the string inside the double-quote characters
|
||||
will be the name of the flags. For example, the flag "sse4_1" comes from
|
||||
@@ -148,36 +155,31 @@ needed. For instance, /proc/cpuinfo is a userspace interface and must remain
|
||||
constant. If, for some reason, the naming of X86_FEATURE_<name> changes, one
|
||||
shall override the new naming with the name already used in /proc/cpuinfo.
|
||||
|
||||
c: The naming override can be "", which means it will not appear in /proc/cpuinfo.
|
||||
----------------------------------------------------------------------------------
|
||||
The feature shall be omitted from /proc/cpuinfo if it does not make sense for
|
||||
the feature to be exposed to userspace. For example, X86_FEATURE_ALWAYS is
|
||||
defined in cpufeatures.h but that flag is an internal kernel feature used
|
||||
in the alternative runtime patching functionality. So, its name is overridden
|
||||
with "". Its flag will not appear in /proc/cpuinfo.
|
||||
|
||||
Flags are missing when one or more of these happen
|
||||
==================================================
|
||||
|
||||
a: The hardware does not enumerate support for it.
|
||||
--------------------------------------------------
|
||||
The hardware does not enumerate support for it
|
||||
----------------------------------------------
|
||||
|
||||
For example, when a new kernel is running on old hardware or the feature is
|
||||
not enabled by boot firmware. Even if the hardware is new, there might be a
|
||||
problem enabling the feature at run time, the flag will not be displayed.
|
||||
|
||||
b: The kernel does not know about the flag.
|
||||
-------------------------------------------
|
||||
The kernel does not know about the flag
|
||||
---------------------------------------
|
||||
|
||||
For example, when an old kernel is running on new hardware.
|
||||
|
||||
c: The kernel disabled support for it at compile-time.
|
||||
------------------------------------------------------
|
||||
The kernel disabled support for it at compile-time
|
||||
--------------------------------------------------
|
||||
|
||||
For example, if 5-level-paging is not enabled when building (i.e.,
|
||||
CONFIG_X86_5LEVEL is not selected) the flag "la57" will not show up [#f1]_.
|
||||
Even though the feature will still be detected via CPUID, the kernel disables
|
||||
it by clearing via setup_clear_cpu_cap(X86_FEATURE_LA57).
|
||||
|
||||
d: The feature is disabled at boot-time.
|
||||
----------------------------------------
|
||||
The feature is disabled at boot-time
|
||||
------------------------------------
|
||||
A feature can be disabled either using a command-line parameter or because
|
||||
it failed to be enabled. The command-line parameter clearcpuid= can be used
|
||||
to disable features using the feature number as defined in
|
||||
@@ -190,8 +192,9 @@ disable specific features. The list of parameters includes, but is not limited
|
||||
to, nofsgsbase, nosgx, noxsave, etc. 5-level paging can also be disabled using
|
||||
"no5lvl".
|
||||
|
||||
e: The feature was known to be non-functional.
|
||||
----------------------------------------------
|
||||
The feature was known to be non-functional
|
||||
------------------------------------------
|
||||
|
||||
The feature was known to be non-functional because a dependency was
|
||||
missing at runtime. For example, AVX flags will not show up if XSAVE feature
|
||||
is disabled since they depend on XSAVE feature. Another example would be broken
|
||||
|
||||
@@ -382,6 +382,14 @@ In case of new BPF instructions, once the changes have been accepted
|
||||
into the Linux kernel, please implement support into LLVM's BPF back
|
||||
end. See LLVM_ section below for further information.
|
||||
|
||||
Q: What "BPF_INTERNAL" symbol namespace is for?
|
||||
-----------------------------------------------
|
||||
A: Symbols exported as BPF_INTERNAL can only be used by BPF infrastructure
|
||||
like preload kernel modules with light skeleton. Most symbols outside
|
||||
of BPF_INTERNAL are not expected to be used by code outside of BPF either.
|
||||
Symbols may lack the designation because they predate the namespaces,
|
||||
or due to an oversight.
|
||||
|
||||
Stable submission
|
||||
=================
|
||||
|
||||
|
||||
@@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Ceva AHCI SATA Controller
|
||||
|
||||
maintainers:
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
description: |
|
||||
|
||||
@@ -111,11 +111,27 @@ properties:
|
||||
unevaluatedProperties: false
|
||||
|
||||
port@1:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
DSI output port node to the panel or the next bridge
|
||||
in the chain
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
data-lanes:
|
||||
description: array of physical DSI data lane indexes.
|
||||
minItems: 1
|
||||
items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
|
||||
required:
|
||||
- port@0
|
||||
- port@1
|
||||
|
||||
@@ -12,7 +12,6 @@ description:
|
||||
PS_MODE). Every pin can be configured as input/output.
|
||||
|
||||
maintainers:
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
properties:
|
||||
|
||||
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Mediatek's Keypad Controller
|
||||
|
||||
maintainers:
|
||||
- Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
||||
- Mattijs Korpershoek <mkorpershoek@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/input/matrix-keymap.yaml#
|
||||
|
||||
@@ -19,6 +19,7 @@ properties:
|
||||
- fsl,imx8mp-irqsteer
|
||||
- fsl,imx8qm-irqsteer
|
||||
- fsl,imx8qxp-irqsteer
|
||||
- fsl,imx94-irqsteer
|
||||
- const: fsl,imx-irqsteer
|
||||
|
||||
reg:
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/can/microchip,mcp2510.yaml#
|
||||
$id: http://devicetree.org/schemas/net/can/microchip,mcp2510.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Microchip MCP251X stand-alone CAN controller
|
||||
|
||||
@@ -74,19 +74,17 @@ properties:
|
||||
- rev-rmii
|
||||
- moca
|
||||
|
||||
# RX and TX delays are added by the MAC when required
|
||||
# RX and TX delays are provided by the PCB. See below
|
||||
- rgmii
|
||||
|
||||
# RGMII with internal RX and TX delays provided by the PHY,
|
||||
# the MAC should not add the RX or TX delays in this case
|
||||
# RX and TX delays are not provided by the PCB. This is the most
|
||||
# frequent case. See below
|
||||
- rgmii-id
|
||||
|
||||
# RGMII with internal RX delay provided by the PHY, the MAC
|
||||
# should not add an RX delay in this case
|
||||
# TX delay is provided by the PCB. See below
|
||||
- rgmii-rxid
|
||||
|
||||
# RGMII with internal TX delay provided by the PHY, the MAC
|
||||
# should not add an TX delay in this case
|
||||
# RX delay is provided by the PCB. See below
|
||||
- rgmii-txid
|
||||
- rtbi
|
||||
- smii
|
||||
@@ -286,4 +284,89 @@ allOf:
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
# Informative
|
||||
# ===========
|
||||
#
|
||||
# 'phy-modes' & 'phy-connection-type' properties 'rgmii', 'rgmii-id',
|
||||
# 'rgmii-rxid', and 'rgmii-txid' are frequently used wrongly by
|
||||
# developers. This informative section clarifies their usage.
|
||||
#
|
||||
# The RGMII specification requires a 2ns delay between the data and
|
||||
# clock signals on the RGMII bus. How this delay is implemented is not
|
||||
# specified.
|
||||
#
|
||||
# One option is to make the clock traces on the PCB longer than the
|
||||
# data traces. A sufficiently difference in length can provide the 2ns
|
||||
# delay. If both the RX and TX delays are implemented in this manner,
|
||||
# 'rgmii' should be used, so indicating the PCB adds the delays.
|
||||
#
|
||||
# If the PCB does not add these delays via extra long traces,
|
||||
# 'rgmii-id' should be used. Here, 'id' refers to 'internal delay',
|
||||
# where either the MAC or PHY adds the delay.
|
||||
#
|
||||
# If only one of the two delays are implemented via extra long clock
|
||||
# lines, either 'rgmii-rxid' or 'rgmii-txid' should be used,
|
||||
# indicating the MAC or PHY should implement one of the delays
|
||||
# internally, while the PCB implements the other delay.
|
||||
#
|
||||
# Device Tree describes hardware, and in this case, it describes the
|
||||
# PCB between the MAC and the PHY, if the PCB implements delays or
|
||||
# not.
|
||||
#
|
||||
# In practice, very few PCBs make use of extra long clock lines. Hence
|
||||
# any RGMII phy mode other than 'rgmii-id' is probably wrong, and is
|
||||
# unlikely to be accepted during review without details provided in
|
||||
# the commit description and comments in the .dts file.
|
||||
#
|
||||
# When the PCB does not implement the delays, the MAC or PHY must. As
|
||||
# such, this is software configuration, and so not described in Device
|
||||
# Tree.
|
||||
#
|
||||
# The following describes how Linux implements the configuration of
|
||||
# the MAC and PHY to add these delays when the PCB does not. As stated
|
||||
# above, developers often get this wrong, and the aim of this section
|
||||
# is reduce the frequency of these errors by Linux developers. Other
|
||||
# users of the Device Tree may implement it differently, and still be
|
||||
# consistent with both the normative and informative description
|
||||
# above.
|
||||
#
|
||||
# By default in Linux, when using phylib/phylink, the MAC is expected
|
||||
# to read the 'phy-mode' from Device Tree, not implement any delays,
|
||||
# and pass the value to the PHY. The PHY will then implement delays as
|
||||
# specified by the 'phy-mode'. The PHY should always be reconfigured
|
||||
# to implement the needed delays, replacing any setting performed by
|
||||
# strapping or the bootloader, etc.
|
||||
#
|
||||
# Experience to date is that all PHYs which implement RGMII also
|
||||
# implement the ability to add or not add the needed delays. Hence
|
||||
# this default is expected to work in all cases. Ignoring this default
|
||||
# is likely to be questioned by Reviews, and require a strong argument
|
||||
# to be accepted.
|
||||
#
|
||||
# There are a small number of cases where the MAC has hard coded
|
||||
# delays which cannot be disabled. The 'phy-mode' only describes the
|
||||
# PCB. The inability to disable the delays in the MAC does not change
|
||||
# the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
|
||||
# 'rgmii' is now invalid, it cannot be supported, since both the PCB
|
||||
# and the MAC and PHY adding delays cannot result in a functional
|
||||
# link. Thus the MAC should report a fatal error for any modes which
|
||||
# cannot be supported. When the MAC implements the delay, it must
|
||||
# ensure that the PHY does not also implement the same delay. So it
|
||||
# must modify the phy-mode it passes to the PHY, removing the delay it
|
||||
# has added. Failure to remove the delay will result in a
|
||||
# non-functioning link.
|
||||
#
|
||||
# Sometimes there is a need to fine tune the delays. Often the MAC or
|
||||
# PHY can perform this fine tuning. In the MAC node, the Device Tree
|
||||
# properties 'rx-internal-delay-ps' and 'tx-internal-delay-ps' should
|
||||
# be used to indicate fine tuning performed by the MAC. The values
|
||||
# expected here are small. A value of 2000ps, i.e 2ns, and a phy-mode
|
||||
# of 'rgmii' will not be accepted by Reviewers.
|
||||
#
|
||||
# If the PHY is to perform fine tuning, the properties
|
||||
# 'rx-internal-delay-ps' and 'tx-internal-delay-ps' in the PHY node
|
||||
# should be used. When the PHY is implementing delays, e.g. 'rgmii-id'
|
||||
# these properties should have a value near to 2000ps. If the PCB is
|
||||
# implementing delays, e.g. 'rgmii', a small value can be used to fine
|
||||
# tune the delay added by the PCB.
|
||||
...
|
||||
|
||||
@@ -27,7 +27,7 @@ properties:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
items:
|
||||
- minimum: 0
|
||||
maximum: 7
|
||||
maximum: 31
|
||||
description:
|
||||
Offset in bit within the address range specified by reg.
|
||||
- minimum: 1
|
||||
|
||||
@@ -19,6 +19,7 @@ properties:
|
||||
- enum:
|
||||
- qcom,apq8064-qfprom
|
||||
- qcom,apq8084-qfprom
|
||||
- qcom,ipq5018-qfprom
|
||||
- qcom,ipq5332-qfprom
|
||||
- qcom,ipq5424-qfprom
|
||||
- qcom,ipq6018-qfprom
|
||||
@@ -28,6 +29,8 @@ properties:
|
||||
- qcom,msm8226-qfprom
|
||||
- qcom,msm8916-qfprom
|
||||
- qcom,msm8917-qfprom
|
||||
- qcom,msm8937-qfprom
|
||||
- qcom,msm8960-qfprom
|
||||
- qcom,msm8974-qfprom
|
||||
- qcom,msm8976-qfprom
|
||||
- qcom,msm8996-qfprom
|
||||
@@ -51,6 +54,7 @@ properties:
|
||||
- qcom,sm8450-qfprom
|
||||
- qcom,sm8550-qfprom
|
||||
- qcom,sm8650-qfprom
|
||||
- qcom,x1e80100-qfprom
|
||||
- const: qcom,qfprom
|
||||
|
||||
reg:
|
||||
|
||||
@@ -14,6 +14,7 @@ properties:
|
||||
enum:
|
||||
- rockchip,px30-otp
|
||||
- rockchip,rk3308-otp
|
||||
- rockchip,rk3576-otp
|
||||
- rockchip,rk3588-otp
|
||||
|
||||
reg:
|
||||
@@ -62,12 +63,34 @@ allOf:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 3
|
||||
clock-names:
|
||||
maxItems: 3
|
||||
resets:
|
||||
maxItems: 1
|
||||
reset-names:
|
||||
items:
|
||||
- const: phy
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- rockchip,rk3576-otp
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 3
|
||||
clock-names:
|
||||
maxItems: 3
|
||||
resets:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
reset-names:
|
||||
items:
|
||||
- const: otp
|
||||
- const: apb
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
@@ -78,6 +101,8 @@ allOf:
|
||||
properties:
|
||||
clocks:
|
||||
minItems: 4
|
||||
clock-names:
|
||||
minItems: 4
|
||||
resets:
|
||||
minItems: 3
|
||||
reset-names:
|
||||
|
||||
@@ -9,15 +9,6 @@ title: Renesas R-Car Timer Pulse Unit PWM Controller
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: renesas,tpu
|
||||
required:
|
||||
- compatible
|
||||
- '#pwm-cells'
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
|
||||
@@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Zynq UltraScale+ MPSoC and Versal reset
|
||||
|
||||
maintainers:
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
description: |
|
||||
|
||||
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Freescale Layerscape Reset Registers Module
|
||||
|
||||
maintainers:
|
||||
- Frank Li
|
||||
- Frank Li <Frank.Li@nxp.com>
|
||||
|
||||
description:
|
||||
Reset Module includes chip reset, service processor control and Reset Control
|
||||
|
||||
@@ -56,19 +56,18 @@ properties:
|
||||
enum:
|
||||
- snps,dw-apb-ssi
|
||||
- snps,dwc-ssi-1.01a
|
||||
- description: Microsemi Ocelot/Jaguar2 SoC SPI Controller
|
||||
items:
|
||||
- enum:
|
||||
- mscc,ocelot-spi
|
||||
- mscc,jaguar2-spi
|
||||
- const: snps,dw-apb-ssi
|
||||
- description: Microchip Sparx5 SoC SPI Controller
|
||||
const: microchip,sparx5-spi
|
||||
- description: Amazon Alpine SPI Controller
|
||||
const: amazon,alpine-dw-apb-ssi
|
||||
- description: Renesas RZ/N1 SPI Controller
|
||||
- description: Vendor controllers which use snps,dw-apb-ssi as fallback
|
||||
items:
|
||||
- const: renesas,rzn1-spi
|
||||
- enum:
|
||||
- mscc,ocelot-spi
|
||||
- mscc,jaguar2-spi
|
||||
- renesas,rzn1-spi
|
||||
- sophgo,sg2042-spi
|
||||
- thead,th1520-spi
|
||||
- const: snps,dw-apb-ssi
|
||||
- description: Intel Keem Bay SPI Controller
|
||||
const: intel,keembay-ssi
|
||||
@@ -88,10 +87,6 @@ properties:
|
||||
- renesas,r9a06g032-spi # RZ/N1D
|
||||
- renesas,r9a06g033-spi # RZ/N1S
|
||||
- const: renesas,rzn1-spi # RZ/N1
|
||||
- description: T-HEAD TH1520 SoC SPI Controller
|
||||
items:
|
||||
- const: thead,th1520-spi
|
||||
- const: snps,dw-apb-ssi
|
||||
|
||||
reg:
|
||||
minItems: 1
|
||||
|
||||
@@ -18,9 +18,14 @@ description: |
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- nxp,imx95-sysctr-timer
|
||||
- nxp,sysctr-timer
|
||||
oneOf:
|
||||
- enum:
|
||||
- nxp,imx95-sysctr-timer
|
||||
- nxp,sysctr-timer
|
||||
- items:
|
||||
- enum:
|
||||
- nxp,imx94-sysctr-timer
|
||||
- const: nxp,imx95-sysctr-timer
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -1,56 +0,0 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/timer/renesas,tpu.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas H8/300 Timer Pulse Unit
|
||||
|
||||
maintainers:
|
||||
- Yoshinori Sato <ysato@users.sourceforge.jp>
|
||||
|
||||
description:
|
||||
The TPU is a 16bit timer/counter with configurable clock inputs and
|
||||
programmable compare match.
|
||||
This implementation supports only cascade mode.
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: renesas,tpu
|
||||
'#pwm-cells': false
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: renesas,tpu
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: First channel
|
||||
- description: Second channel
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
const: fck
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
tpu: tpu@ffffe0 {
|
||||
compatible = "renesas,tpu";
|
||||
reg = <0xffffe0 16>, <0xfffff0 12>;
|
||||
clocks = <&pclk>;
|
||||
clock-names = "fck";
|
||||
};
|
||||
@@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Xilinx SuperSpeed DWC3 USB SoC controller
|
||||
|
||||
maintainers:
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
properties:
|
||||
|
||||
@@ -17,7 +17,6 @@ description:
|
||||
|
||||
maintainers:
|
||||
- Michal Simek <michal.simek@amd.com>
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
properties:
|
||||
|
||||
@@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Xilinx udc controller
|
||||
|
||||
maintainers:
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
properties:
|
||||
|
||||
@@ -328,9 +328,13 @@ The ext4 superblock is laid out as follows in
|
||||
- s_checksum_type
|
||||
- Metadata checksum algorithm type. The only valid value is 1 (crc32c).
|
||||
* - 0x176
|
||||
- __le16
|
||||
- s_reserved_pad
|
||||
-
|
||||
- \_\_u8
|
||||
- s\_encryption\_level
|
||||
- Versioning level for encryption.
|
||||
* - 0x177
|
||||
- \_\_u8
|
||||
- s\_reserved\_pad
|
||||
- Padding to next 32bits.
|
||||
* - 0x178
|
||||
- __le64
|
||||
- s_kbytes_written
|
||||
@@ -466,9 +470,13 @@ The ext4 superblock is laid out as follows in
|
||||
- s_last_error_time_hi
|
||||
- Upper 8 bits of the s_last_error_time field.
|
||||
* - 0x27A
|
||||
- __u8
|
||||
- s_pad[2]
|
||||
- Zero padding.
|
||||
- \_\_u8
|
||||
- s\_first\_error\_errcode
|
||||
-
|
||||
* - 0x27B
|
||||
- \_\_u8
|
||||
- s\_last\_error\_errcode
|
||||
-
|
||||
* - 0x27C
|
||||
- __le16
|
||||
- s_encoding
|
||||
|
||||
@@ -46,6 +46,21 @@ The kernel embeds the building user and host names in
|
||||
`KBUILD_BUILD_USER and KBUILD_BUILD_HOST`_ variables. If you are
|
||||
building from a git commit, you could use its committer address.
|
||||
|
||||
Absolute filenames
|
||||
------------------
|
||||
|
||||
When the kernel is built out-of-tree, debug information may include
|
||||
absolute filenames for the source files. This must be overridden by
|
||||
including the ``-fdebug-prefix-map`` option in the `KCFLAGS`_ variable.
|
||||
|
||||
Depending on the compiler used, the ``__FILE__`` macro may also expand
|
||||
to an absolute filename in an out-of-tree build. Kbuild automatically
|
||||
uses the ``-fmacro-prefix-map`` option to prevent this, if it is
|
||||
supported.
|
||||
|
||||
The Reproducible Builds web site has more information about these
|
||||
`prefix-map options`_.
|
||||
|
||||
Generated files in source packages
|
||||
----------------------------------
|
||||
|
||||
@@ -116,5 +131,7 @@ See ``scripts/setlocalversion`` for details.
|
||||
|
||||
.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp
|
||||
.. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host
|
||||
.. _KCFLAGS: kbuild.html#kcflags
|
||||
.. _prefix-map options: https://reproducible-builds.org/docs/build-path/
|
||||
.. _Reproducible Builds project: https://reproducible-builds.org/
|
||||
.. _SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/
|
||||
|
||||
@@ -89,8 +89,10 @@ definitions:
|
||||
doc: Group of short_detected states
|
||||
-
|
||||
name: phy-upstream-type
|
||||
enum-name:
|
||||
enum-name: phy-upstream
|
||||
header: linux/ethtool.h
|
||||
type: enum
|
||||
name-prefix: phy-upstream
|
||||
entries: [ mac, phy ]
|
||||
-
|
||||
name: tcp-data-split
|
||||
|
||||
@@ -123,12 +123,12 @@ attribute-sets:
|
||||
|
||||
operations:
|
||||
name-prefix: ovs-vport-cmd-
|
||||
fixed-header: ovs-header
|
||||
list:
|
||||
-
|
||||
name: new
|
||||
doc: Create a new OVS vport
|
||||
attribute-set: vport
|
||||
fixed-header: ovs-header
|
||||
do:
|
||||
request:
|
||||
attributes:
|
||||
@@ -141,7 +141,6 @@ operations:
|
||||
name: del
|
||||
doc: Delete existing OVS vport from a data path
|
||||
attribute-set: vport
|
||||
fixed-header: ovs-header
|
||||
do:
|
||||
request:
|
||||
attributes:
|
||||
@@ -152,7 +151,6 @@ operations:
|
||||
name: get
|
||||
doc: Get / dump OVS vport configuration and state
|
||||
attribute-set: vport
|
||||
fixed-header: ovs-header
|
||||
do: &vport-get-op
|
||||
request:
|
||||
attributes:
|
||||
|
||||
@@ -1113,11 +1113,10 @@ attribute-sets:
|
||||
-
|
||||
name: prop-list
|
||||
type: nest
|
||||
nested-attributes: link-attrs
|
||||
nested-attributes: prop-list-link-attrs
|
||||
-
|
||||
name: alt-ifname
|
||||
type: string
|
||||
multi-attr: true
|
||||
-
|
||||
name: perm-address
|
||||
type: binary
|
||||
@@ -1163,6 +1162,13 @@ attribute-sets:
|
||||
-
|
||||
name: netns-immutable
|
||||
type: u8
|
||||
-
|
||||
name: prop-list-link-attrs
|
||||
subset-of: link-attrs
|
||||
attributes:
|
||||
-
|
||||
name: alt-ifname
|
||||
multi-attr: true
|
||||
-
|
||||
name: af-spec-attrs
|
||||
attributes:
|
||||
@@ -1585,7 +1591,7 @@ attribute-sets:
|
||||
name: nf-call-iptables
|
||||
type: u8
|
||||
-
|
||||
name: nf-call-ip6-tables
|
||||
name: nf-call-ip6tables
|
||||
type: u8
|
||||
-
|
||||
name: nf-call-arptables
|
||||
@@ -2077,7 +2083,7 @@ attribute-sets:
|
||||
name: id
|
||||
type: u16
|
||||
-
|
||||
name: flag
|
||||
name: flags
|
||||
type: binary
|
||||
struct: ifla-vlan-flags
|
||||
-
|
||||
@@ -2165,7 +2171,7 @@ attribute-sets:
|
||||
type: binary
|
||||
struct: ifla-cacheinfo
|
||||
-
|
||||
name: icmp6-stats
|
||||
name: icmp6stats
|
||||
type: binary
|
||||
struct: ifla-icmp6-stats
|
||||
-
|
||||
@@ -2179,9 +2185,10 @@ attribute-sets:
|
||||
type: u32
|
||||
-
|
||||
name: mctp-attrs
|
||||
name-prefix: ifla-mctp-
|
||||
attributes:
|
||||
-
|
||||
name: mctp-net
|
||||
name: net
|
||||
type: u32
|
||||
-
|
||||
name: phys-binding
|
||||
@@ -2453,7 +2460,6 @@ operations:
|
||||
- min-mtu
|
||||
- max-mtu
|
||||
- prop-list
|
||||
- alt-ifname
|
||||
- perm-address
|
||||
- proto-down-reason
|
||||
- parent-dev-name
|
||||
|
||||
@@ -13,25 +13,25 @@ definitions:
|
||||
type: struct
|
||||
members:
|
||||
-
|
||||
name: family
|
||||
name: ndm-family
|
||||
type: u8
|
||||
-
|
||||
name: pad
|
||||
name: ndm-pad
|
||||
type: pad
|
||||
len: 3
|
||||
-
|
||||
name: ifindex
|
||||
name: ndm-ifindex
|
||||
type: s32
|
||||
-
|
||||
name: state
|
||||
name: ndm-state
|
||||
type: u16
|
||||
enum: nud-state
|
||||
-
|
||||
name: flags
|
||||
name: ndm-flags
|
||||
type: u8
|
||||
enum: ntf-flags
|
||||
-
|
||||
name: type
|
||||
name: ndm-type
|
||||
type: u8
|
||||
enum: rtm-type
|
||||
-
|
||||
@@ -189,7 +189,7 @@ attribute-sets:
|
||||
type: binary
|
||||
display-hint: ipv4
|
||||
-
|
||||
name: lladr
|
||||
name: lladdr
|
||||
type: binary
|
||||
display-hint: mac
|
||||
-
|
||||
|
||||
@@ -2017,7 +2017,8 @@ attribute-sets:
|
||||
attributes:
|
||||
-
|
||||
name: act
|
||||
type: nest
|
||||
type: indexed-array
|
||||
sub-type: nest
|
||||
nested-attributes: tc-act-attrs
|
||||
-
|
||||
name: police
|
||||
@@ -2250,7 +2251,8 @@ attribute-sets:
|
||||
attributes:
|
||||
-
|
||||
name: act
|
||||
type: nest
|
||||
type: indexed-array
|
||||
sub-type: nest
|
||||
nested-attributes: tc-act-attrs
|
||||
-
|
||||
name: police
|
||||
@@ -2745,7 +2747,7 @@ attribute-sets:
|
||||
type: u16
|
||||
byte-order: big-endian
|
||||
-
|
||||
name: key-l2-tpv3-sid
|
||||
name: key-l2tpv3-sid
|
||||
type: u32
|
||||
byte-order: big-endian
|
||||
-
|
||||
@@ -3504,7 +3506,7 @@ attribute-sets:
|
||||
name: rate64
|
||||
type: u64
|
||||
-
|
||||
name: prate4
|
||||
name: prate64
|
||||
type: u64
|
||||
-
|
||||
name: burst
|
||||
|
||||
@@ -338,10 +338,11 @@ operations directly under the netdev instance lock.
|
||||
Devices drivers are encouraged to rely on the instance lock where possible.
|
||||
|
||||
For the (mostly software) drivers that need to interact with the core stack,
|
||||
there are two sets of interfaces: ``dev_xxx`` and ``netif_xxx`` (e.g.,
|
||||
``dev_set_mtu`` and ``netif_set_mtu``). The ``dev_xxx`` functions handle
|
||||
acquiring the instance lock themselves, while the ``netif_xxx`` functions
|
||||
assume that the driver has already acquired the instance lock.
|
||||
there are two sets of interfaces: ``dev_xxx``/``netdev_xxx`` and ``netif_xxx``
|
||||
(e.g., ``dev_set_mtu`` and ``netif_set_mtu``). The ``dev_xxx``/``netdev_xxx``
|
||||
functions handle acquiring the instance lock themselves, while the
|
||||
``netif_xxx`` functions assume that the driver has already acquired
|
||||
the instance lock.
|
||||
|
||||
Notifiers and netdev instance lock
|
||||
==================================
|
||||
@@ -354,6 +355,7 @@ For devices with locked ops, currently only the following notifiers are
|
||||
running under the lock:
|
||||
* ``NETDEV_REGISTER``
|
||||
* ``NETDEV_UP``
|
||||
* ``NETDEV_CHANGE``
|
||||
|
||||
The following notifiers are running without the lock:
|
||||
* ``NETDEV_UNREGISTER``
|
||||
|
||||
@@ -811,11 +811,9 @@ Documentation/devicetree/bindings/ptp/timestamper.txt for more details.
|
||||
3.2.4 Other caveats for MAC drivers
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Stacked PHCs, especially DSA (but not only) - since that doesn't require any
|
||||
modification to MAC drivers, so it is more difficult to ensure correctness of
|
||||
all possible code paths - is that they uncover bugs which were impossible to
|
||||
trigger before the existence of stacked PTP clocks. One example has to do with
|
||||
this line of code, already presented earlier::
|
||||
The use of stacked PHCs may uncover MAC driver bugs which were impossible to
|
||||
trigger without them. One example has to do with this line of code, already
|
||||
presented earlier::
|
||||
|
||||
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
|
||||
|
||||
|
||||
@@ -154,7 +154,7 @@ suspending the device are satisfied) and to queue up a suspend request for the
|
||||
device in that case. If there is no idle callback, or if the callback returns
|
||||
0, then the PM core will attempt to carry out a runtime suspend of the device,
|
||||
also respecting devices configured for autosuspend. In essence this means a
|
||||
call to __pm_runtime_autosuspend() (do note that drivers needs to update the
|
||||
call to pm_runtime_autosuspend() (do note that drivers needs to update the
|
||||
device last busy mark, pm_runtime_mark_last_busy(), to control the delay under
|
||||
this circumstance). To prevent this (for example, if the callback routine has
|
||||
started a delayed suspend), the routine must return a non-zero value. Negative
|
||||
|
||||
@@ -17,10 +17,10 @@ OpenRISC 1000系列（或1k）。
|
||||
|
||||
关于OpenRISC处理器和正在进行中的开发的信息:
|
||||
|
||||
======= =============================
|
||||
======= ==============================
|
||||
网站 https://openrisc.io
|
||||
邮箱 openrisc@lists.librecores.org
|
||||
======= =============================
|
||||
邮箱 linux-openrisc@vger.kernel.org
|
||||
======= ==============================
|
||||
|
||||
---------------------------------------------------------------------
|
||||
|
||||
@@ -36,11 +36,11 @@ OpenRISC工具链和Linux的构建指南
|
||||
工具链的构建指南可以在openrisc.io或Stafford的工具链构建和发布脚本
|
||||
中找到。
|
||||
|
||||
====== =================================================
|
||||
二进制 https://github.com/openrisc/or1k-gcc/releases
|
||||
====== ==========================================================
|
||||
二进制 https://github.com/stffrdhrn/or1k-toolchain-build/releases
|
||||
工具链 https://openrisc.io/software
|
||||
构建 https://github.com/stffrdhrn/or1k-toolchain-build
|
||||
====== =================================================
|
||||
====== ==========================================================
|
||||
|
||||
2) 构建
|
||||
|
||||
|
||||
@@ -17,10 +17,10 @@ OpenRISC 1000系列（或1k）。
|
||||
|
||||
關於OpenRISC處理器和正在進行中的開發的信息:
|
||||
|
||||
======= =============================
|
||||
======= ==============================
|
||||
網站 https://openrisc.io
|
||||
郵箱 openrisc@lists.librecores.org
|
||||
======= =============================
|
||||
郵箱 linux-openrisc@vger.kernel.org
|
||||
======= ==============================
|
||||
|
||||
---------------------------------------------------------------------
|
||||
|
||||
@@ -36,11 +36,11 @@ OpenRISC工具鏈和Linux的構建指南
|
||||
工具鏈的構建指南可以在openrisc.io或Stafford的工具鏈構建和發佈腳本
|
||||
中找到。
|
||||
|
||||
====== =================================================
|
||||
二進制 https://github.com/openrisc/or1k-gcc/releases
|
||||
====== ==========================================================
|
||||
二進制 https://github.com/stffrdhrn/or1k-toolchain-build/releases
|
||||
工具鏈 https://openrisc.io/software
|
||||
構建 https://github.com/stffrdhrn/or1k-toolchain-build
|
||||
====== =================================================
|
||||
====== ==========================================================
|
||||
|
||||
2) 構建
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ SYSCALL
|
||||
=======
|
||||
mseal syscall signature
|
||||
-----------------------
|
||||
``int mseal(void \* addr, size_t len, unsigned long flags)``
|
||||
``int mseal(void *addr, size_t len, unsigned long flags)``
|
||||
|
||||
**addr**/**len**: virtual memory address range.
|
||||
The address range set by **addr**/**len** must meet:
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -138,6 +138,10 @@ input data, the meaning of which depends on the subfeature being accessed.
|
||||
The output buffer contains a single byte which signals success or failure (``0x00`` on failure)
|
||||
and 31 bytes of output data, the meaning if which depends on the subfeature being accessed.
|
||||
|
||||
.. note::
|
||||
The ACPI control method responsible for handling the WMI method calls is not thread-safe.
|
||||
This is a firmware bug that needs to be handled inside the driver itself.
|
||||
|
||||
WMI method Get_EC()
|
||||
-------------------
|
||||
|
||||
|
||||
281
MAINTAINERS
281
MAINTAINERS
@@ -2519,6 +2519,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
|
||||
F: arch/arm/boot/dts/nxp/imx/
|
||||
F: arch/arm/boot/dts/nxp/mxs/
|
||||
F: arch/arm64/boot/dts/freescale/
|
||||
X: Documentation/devicetree/bindings/media/i2c/
|
||||
X: arch/arm64/boot/dts/freescale/fsl-*
|
||||
X: arch/arm64/boot/dts/freescale/qoriq-*
|
||||
X: drivers/media/i2c/
|
||||
@@ -3191,6 +3192,12 @@ M: Dinh Nguyen <dinguyen@kernel.org>
|
||||
S: Maintained
|
||||
F: drivers/clk/socfpga/
|
||||
|
||||
ARM/SOCFPGA DWMAC GLUE LAYER
|
||||
M: Maxime Chevallier <maxime.chevallier@bootlin.com>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/socfpga-dwmac.txt
|
||||
F: drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
|
||||
|
||||
ARM/SOCFPGA EDAC BINDINGS
|
||||
M: Matthew Gerlach <matthew.gerlach@altera.com>
|
||||
S: Maintained
|
||||
@@ -3867,8 +3874,9 @@ AUXILIARY BUS DRIVER
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
R: Dave Ertman <david.m.ertman@intel.com>
|
||||
R: Ira Weiny <ira.weiny@intel.com>
|
||||
R: Leon Romanovsky <leon@kernel.org>
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
|
||||
F: Documentation/driver-api/auxiliary_bus.rst
|
||||
F: drivers/base/auxiliary.c
|
||||
F: include/linux/auxiliary_bus.h
|
||||
@@ -6335,6 +6343,7 @@ F: Documentation/process/cve.rst
|
||||
|
||||
CW1200 WLAN driver
|
||||
S: Orphan
|
||||
L: linux-wireless@vger.kernel.org
|
||||
F: drivers/net/wireless/st/
|
||||
F: include/linux/platform_data/net-cw1200.h
|
||||
|
||||
@@ -7020,6 +7029,7 @@ L: rust-for-linux@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://rust-for-linux.com
|
||||
T: git https://github.com/Rust-for-Linux/linux.git alloc-next
|
||||
F: rust/helpers/dma.c
|
||||
F: rust/kernel/dma.rs
|
||||
F: samples/rust/rust_dma.rs
|
||||
|
||||
@@ -7225,7 +7235,7 @@ M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
M: "Rafael J. Wysocki" <rafael@kernel.org>
|
||||
M: Danilo Krummrich <dakr@kernel.org>
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
|
||||
F: Documentation/core-api/kobject.rst
|
||||
F: drivers/base/
|
||||
F: fs/debugfs/
|
||||
@@ -8717,6 +8727,7 @@ M: Chao Yu <chao@kernel.org>
|
||||
R: Yue Hu <zbestahu@gmail.com>
|
||||
R: Jeffle Xu <jefflexu@linux.alibaba.com>
|
||||
R: Sandeep Dhavale <dhavale@google.com>
|
||||
R: Hongbo Li <lihongbo22@huawei.com>
|
||||
L: linux-erofs@lists.ozlabs.org
|
||||
S: Maintained
|
||||
W: https://erofs.docs.kernel.org
|
||||
@@ -10136,6 +10147,13 @@ F: drivers/gpio/gpio-regmap.c
|
||||
F: include/linux/gpio/regmap.h
|
||||
K: (devm_)?gpio_regmap_(un)?register
|
||||
|
||||
GPIO SLOPPY LOGIC ANALYZER
|
||||
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
|
||||
S: Supported
|
||||
F: Documentation/dev-tools/gpio-sloppy-logic-analyzer.rst
|
||||
F: drivers/gpio/gpio-sloppy-logic-analyzer.c
|
||||
F: tools/gpio/gpio-sloppy-logic-analyzer.sh
|
||||
|
||||
GPIO SUBSYSTEM
|
||||
M: Linus Walleij <linus.walleij@linaro.org>
|
||||
M: Bartosz Golaszewski <brgl@bgdev.pl>
|
||||
@@ -10151,6 +10169,8 @@ F: include/linux/gpio.h
|
||||
F: include/linux/gpio/
|
||||
F: include/linux/of_gpio.h
|
||||
K: (devm_)?gpio_(request|free|direction|get|set)
|
||||
K: GPIOD_FLAGS_BIT_NONEXCLUSIVE
|
||||
K: devm_gpiod_unhinge
|
||||
|
||||
GPIO UAPI
|
||||
M: Bartosz Golaszewski <brgl@bgdev.pl>
|
||||
@@ -10453,14 +10473,20 @@ S: Supported
|
||||
F: drivers/infiniband/hw/hfi1
|
||||
|
||||
HFS FILESYSTEM
|
||||
M: Viacheslav Dubeyko <slava@dubeyko.com>
|
||||
M: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
M: Yangtao Li <frank.li@vivo.com>
|
||||
L: linux-fsdevel@vger.kernel.org
|
||||
S: Orphan
|
||||
S: Maintained
|
||||
F: Documentation/filesystems/hfs.rst
|
||||
F: fs/hfs/
|
||||
|
||||
HFSPLUS FILESYSTEM
|
||||
M: Viacheslav Dubeyko <slava@dubeyko.com>
|
||||
M: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
M: Yangtao Li <frank.li@vivo.com>
|
||||
L: linux-fsdevel@vger.kernel.org
|
||||
S: Orphan
|
||||
S: Maintained
|
||||
F: Documentation/filesystems/hfsplus.rst
|
||||
F: fs/hfsplus/
|
||||
|
||||
@@ -10954,6 +10980,7 @@ F: include/linux/platform_data/huawei-gaokun-ec.h
|
||||
|
||||
HUGETLB SUBSYSTEM
|
||||
M: Muchun Song <muchun.song@linux.dev>
|
||||
R: Oscar Salvador <osalvador@suse.de>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
F: Documentation/ABI/testing/sysfs-kernel-mm-hugepages
|
||||
@@ -11079,6 +11106,14 @@ L: linuxppc-dev@lists.ozlabs.org
|
||||
S: Odd Fixes
|
||||
F: drivers/tty/hvc/
|
||||
|
||||
HUNG TASK DETECTOR
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
R: Lance Yang <lance.yang@linux.dev>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: include/linux/hung_task.h
|
||||
F: kernel/hung_task.c
|
||||
|
||||
I2C ACPI SUPPORT
|
||||
M: Mika Westerberg <westeri@kernel.org>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
@@ -11217,7 +11252,6 @@ S: Maintained
|
||||
F: drivers/i2c/busses/i2c-cht-wc.c
|
||||
|
||||
I2C/SMBUS ISMT DRIVER
|
||||
M: Seth Heasley <seth.heasley@intel.com>
|
||||
M: Neil Horman <nhorman@tuxdriver.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
F: Documentation/i2c/busses/i2c-ismt.rst
|
||||
@@ -12810,6 +12844,7 @@ F: lib/Kconfig.kcsan
|
||||
F: scripts/Makefile.kcsan
|
||||
|
||||
KDUMP
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Baoquan He <bhe@redhat.com>
|
||||
R: Vivek Goyal <vgoyal@redhat.com>
|
||||
R: Dave Young <dyoung@redhat.com>
|
||||
@@ -13106,11 +13141,13 @@ KERNFS
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
M: Tejun Heo <tj@kernel.org>
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
|
||||
F: fs/kernfs/
|
||||
F: include/linux/kernfs.h
|
||||
|
||||
KEXEC
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Baoquan He <bhe@redhat.com>
|
||||
L: kexec@lists.infradead.org
|
||||
W: http://kernel.org/pub/linux/utils/kernel/kexec/
|
||||
F: include/linux/kexec.h
|
||||
@@ -14283,6 +14320,7 @@ S: Odd fixes
|
||||
F: drivers/net/ethernet/marvell/sk*
|
||||
|
||||
MARVELL LIBERTAS WIRELESS DRIVER
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: libertas-dev@lists.infradead.org
|
||||
S: Orphan
|
||||
F: drivers/net/wireless/marvell/libertas/
|
||||
@@ -15049,7 +15087,7 @@ F: Documentation/devicetree/bindings/media/mediatek-jpeg-*.yaml
|
||||
F: drivers/media/platform/mediatek/jpeg/
|
||||
|
||||
MEDIATEK KEYPAD DRIVER
|
||||
M: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
||||
M: Mattijs Korpershoek <mkorpershoek@kernel.org>
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml
|
||||
F: drivers/input/keyboard/mt6779-keypad.c
|
||||
@@ -15472,24 +15510,45 @@ F: Documentation/mm/
|
||||
F: include/linux/gfp.h
|
||||
F: include/linux/gfp_types.h
|
||||
F: include/linux/memfd.h
|
||||
F: include/linux/memory.h
|
||||
F: include/linux/memory_hotplug.h
|
||||
F: include/linux/memory-tiers.h
|
||||
F: include/linux/mempolicy.h
|
||||
F: include/linux/mempool.h
|
||||
F: include/linux/memremap.h
|
||||
F: include/linux/mm.h
|
||||
F: include/linux/mm_*.h
|
||||
F: include/linux/mmzone.h
|
||||
F: include/linux/mmu_notifier.h
|
||||
F: include/linux/pagewalk.h
|
||||
F: include/linux/rmap.h
|
||||
F: include/trace/events/ksm.h
|
||||
F: mm/
|
||||
F: tools/mm/
|
||||
F: tools/testing/selftests/mm/
|
||||
N: include/linux/page[-_]*
|
||||
|
||||
MEMORY MANAGEMENT - CORE
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Mike Rapoport <rppt@kernel.org>
|
||||
R: Suren Baghdasaryan <surenb@google.com>
|
||||
R: Michal Hocko <mhocko@suse.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: include/linux/memory.h
|
||||
F: include/linux/mm.h
|
||||
F: include/linux/mm_*.h
|
||||
F: include/linux/mmdebug.h
|
||||
F: include/linux/pagewalk.h
|
||||
F: mm/Kconfig
|
||||
F: mm/debug.c
|
||||
F: mm/init-mm.c
|
||||
F: mm/memory.c
|
||||
F: mm/pagewalk.c
|
||||
F: mm/util.c
|
||||
|
||||
MEMORY MANAGEMENT - EXECMEM
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Mike Rapoport <rppt@kernel.org>
|
||||
@@ -15498,6 +15557,53 @@ S: Maintained
|
||||
F: include/linux/execmem.h
|
||||
F: mm/execmem.c
|
||||
|
||||
MEMORY MANAGEMENT - GUP (GET USER PAGES)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
R: Jason Gunthorpe <jgg@nvidia.com>
|
||||
R: John Hubbard <jhubbard@nvidia.com>
|
||||
R: Peter Xu <peterx@redhat.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: mm/gup.c
|
||||
|
||||
MEMORY MANAGEMENT - KSM (Kernel Samepage Merging)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
R: Xu Xin <xu.xin16@zte.com.cn>
|
||||
R: Chengming Zhou <chengming.zhou@linux.dev>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: Documentation/admin-guide/mm/ksm.rst
|
||||
F: Documentation/mm/ksm.rst
|
||||
F: include/linux/ksm.h
|
||||
F: include/trace/events/ksm.h
|
||||
F: mm/ksm.c
|
||||
|
||||
MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
R: Zi Yan <ziy@nvidia.com>
|
||||
R: Matthew Brost <matthew.brost@intel.com>
|
||||
R: Joshua Hahn <joshua.hahnjy@gmail.com>
|
||||
R: Rakie Kim <rakie.kim@sk.com>
|
||||
R: Byungchul Park <byungchul@sk.com>
|
||||
R: Gregory Price <gourry@gourry.net>
|
||||
R: Ying Huang <ying.huang@linux.alibaba.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: include/linux/mempolicy.h
|
||||
F: include/linux/migrate.h
|
||||
F: mm/mempolicy.c
|
||||
F: mm/migrate.c
|
||||
F: mm/migrate_device.c
|
||||
|
||||
MEMORY MANAGEMENT - NUMA MEMBLOCKS AND NUMA EMULATION
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Mike Rapoport <rppt@kernel.org>
|
||||
@@ -15508,6 +15614,49 @@ F: mm/numa.c
|
||||
F: mm/numa_emulation.c
|
||||
F: mm/numa_memblks.c
|
||||
|
||||
MEMORY MANAGEMENT - PAGE ALLOCATOR
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Suren Baghdasaryan <surenb@google.com>
|
||||
R: Michal Hocko <mhocko@suse.com>
|
||||
R: Brendan Jackman <jackmanb@google.com>
|
||||
R: Johannes Weiner <hannes@cmpxchg.org>
|
||||
R: Zi Yan <ziy@nvidia.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
F: include/linux/compaction.h
|
||||
F: include/linux/gfp.h
|
||||
F: include/linux/page-isolation.h
|
||||
F: mm/compaction.c
|
||||
F: mm/page_alloc.c
|
||||
F: mm/page_isolation.c
|
||||
|
||||
MEMORY MANAGEMENT - RECLAIM
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Johannes Weiner <hannes@cmpxchg.org>
|
||||
R: David Hildenbrand <david@redhat.com>
|
||||
R: Michal Hocko <mhocko@kernel.org>
|
||||
R: Qi Zheng <zhengqi.arch@bytedance.com>
|
||||
R: Shakeel Butt <shakeel.butt@linux.dev>
|
||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
F: mm/pt_reclaim.c
|
||||
F: mm/vmscan.c
|
||||
|
||||
MEMORY MANAGEMENT - RMAP (REVERSE MAPPING)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Rik van Riel <riel@surriel.com>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Harry Yoo <harry.yoo@oracle.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
F: include/linux/rmap.h
|
||||
F: mm/rmap.c
|
||||
|
||||
MEMORY MANAGEMENT - SECRETMEM
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Mike Rapoport <rppt@kernel.org>
|
||||
@@ -15516,6 +15665,30 @@ S: Maintained
|
||||
F: include/linux/secretmem.h
|
||||
F: mm/secretmem.c
|
||||
|
||||
MEMORY MANAGEMENT - THP (TRANSPARENT HUGE PAGE)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
R: Zi Yan <ziy@nvidia.com>
|
||||
R: Baolin Wang <baolin.wang@linux.alibaba.com>
|
||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
R: Nico Pache <npache@redhat.com>
|
||||
R: Ryan Roberts <ryan.roberts@arm.com>
|
||||
R: Dev Jain <dev.jain@arm.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: Documentation/admin-guide/mm/transhuge.rst
|
||||
F: include/linux/huge_mm.h
|
||||
F: include/linux/khugepaged.h
|
||||
F: include/trace/events/huge_memory.h
|
||||
F: mm/huge_memory.c
|
||||
F: mm/khugepaged.c
|
||||
F: tools/testing/selftests/mm/khugepaged.c
|
||||
F: tools/testing/selftests/mm/split_huge_page_test.c
|
||||
F: tools/testing/selftests/mm/transhuge-stress.c
|
||||
|
||||
MEMORY MANAGEMENT - USERFAULTFD
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
R: Peter Xu <peterx@redhat.com>
|
||||
@@ -15535,10 +15708,12 @@ M: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Jann Horn <jannh@google.com>
|
||||
R: Pedro Falcato <pfalcato@suse.de>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: include/trace/events/mmap.h
|
||||
F: mm/mlock.c
|
||||
F: mm/mmap.c
|
||||
F: mm/mprotect.c
|
||||
@@ -15549,6 +15724,36 @@ F: mm/vma.h
|
||||
F: mm/vma_internal.h
|
||||
F: tools/testing/vma/
|
||||
|
||||
MEMORY MAPPING - LOCKING
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Suren Baghdasaryan <surenb@google.com>
|
||||
M: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Shakeel Butt <shakeel.butt@linux.dev>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: Documentation/mm/process_addrs.rst
|
||||
F: include/linux/mmap_lock.h
|
||||
F: include/trace/events/mmap_lock.h
|
||||
F: mm/mmap_lock.c
|
||||
|
||||
MEMORY MAPPING - MADVISE (MEMORY ADVICE)
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
M: David Hildenbrand <david@redhat.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Jann Horn <jannh@google.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: include/uapi/asm-generic/mman-common.h
|
||||
F: mm/madvise.c
|
||||
|
||||
MEMORY TECHNOLOGY DEVICES (MTD)
|
||||
M: Miquel Raynal <miquel.raynal@bootlin.com>
|
||||
M: Richard Weinberger <richard@nod.at>
|
||||
@@ -16756,6 +16961,7 @@ F: Documentation/networking/net_cachelines/net_device.rst
|
||||
F: drivers/connector/
|
||||
F: drivers/net/
|
||||
F: drivers/ptp/
|
||||
F: drivers/s390/net/
|
||||
F: include/dt-bindings/net/
|
||||
F: include/linux/cn_proc.h
|
||||
F: include/linux/etherdevice.h
|
||||
@@ -16765,6 +16971,7 @@ F: include/linux/fddidevice.h
|
||||
F: include/linux/hippidevice.h
|
||||
F: include/linux/if_*
|
||||
F: include/linux/inetdevice.h
|
||||
F: include/linux/ism.h
|
||||
F: include/linux/netdev*
|
||||
F: include/linux/platform_data/wiznet.h
|
||||
F: include/uapi/linux/cn_proc.h
|
||||
@@ -17368,7 +17575,7 @@ T: git git://git.infradead.org/nvme.git
|
||||
F: drivers/nvme/target/
|
||||
|
||||
NVMEM FRAMEWORK
|
||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
M: Srinivas Kandagatla <srini@kernel.org>
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/srini/nvmem.git
|
||||
F: Documentation/ABI/stable/sysfs-bus-nvmem
|
||||
@@ -18302,7 +18509,7 @@ F: include/uapi/linux/ppdev.h
|
||||
PARAVIRT_OPS INTERFACE
|
||||
M: Juergen Gross <jgross@suse.com>
|
||||
R: Ajay Kaher <ajay.kaher@broadcom.com>
|
||||
R: Alexey Makhalov <alexey.amakhalov@broadcom.com>
|
||||
R: Alexey Makhalov <alexey.makhalov@broadcom.com>
|
||||
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
|
||||
L: virtualization@lists.linux.dev
|
||||
L: x86@kernel.org
|
||||
@@ -18633,7 +18840,7 @@ F: drivers/pci/controller/pci-xgene-msi.c
|
||||
PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS
|
||||
M: Lorenzo Pieralisi <lpieralisi@kernel.org>
|
||||
M: Krzysztof Wilczyński <kw@linux.com>
|
||||
R: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
||||
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
||||
R: Rob Herring <robh@kernel.org>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
@@ -18686,6 +18893,16 @@ F: include/asm-generic/pci*
|
||||
F: include/linux/of_pci.h
|
||||
F: include/linux/pci*
|
||||
F: include/uapi/linux/pci*
|
||||
|
||||
PCI SUBSYSTEM [RUST]
|
||||
M: Danilo Krummrich <dakr@kernel.org>
|
||||
R: Bjorn Helgaas <bhelgaas@google.com>
|
||||
R: Krzysztof Wilczyński <kwilczynski@kernel.org>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
C: irc://irc.oftc.net/linux-pci
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
|
||||
F: rust/helpers/pci.c
|
||||
F: rust/kernel/pci.rs
|
||||
F: samples/rust/rust_driver_pci.rs
|
||||
|
||||
@@ -19573,7 +19790,7 @@ S: Supported
|
||||
F: drivers/crypto/intel/qat/
|
||||
|
||||
QCOM AUDIO (ASoC) DRIVERS
|
||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
M: Srinivas Kandagatla <srini@kernel.org>
|
||||
L: linux-sound@vger.kernel.org
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Supported
|
||||
@@ -19746,6 +19963,7 @@ F: drivers/media/tuners/qt1010*
|
||||
|
||||
QUALCOMM ATH12K WIRELESS DRIVER
|
||||
M: Jeff Johnson <jjohnson@kernel.org>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: ath12k@lists.infradead.org
|
||||
S: Supported
|
||||
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath12k
|
||||
@@ -19755,6 +19973,7 @@ N: ath12k
|
||||
|
||||
QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
|
||||
M: Jeff Johnson <jjohnson@kernel.org>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: ath10k@lists.infradead.org
|
||||
S: Supported
|
||||
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
|
||||
@@ -19764,6 +19983,7 @@ N: ath10k
|
||||
|
||||
QUALCOMM ATHEROS ATH11K WIRELESS DRIVER
|
||||
M: Jeff Johnson <jjohnson@kernel.org>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: ath11k@lists.infradead.org
|
||||
S: Supported
|
||||
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k
|
||||
@@ -19873,7 +20093,7 @@ F: Documentation/devicetree/bindings/net/qcom,ethqos.yaml
|
||||
F: drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
|
||||
|
||||
QUALCOMM FASTRPC DRIVER
|
||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
M: Srinivas Kandagatla <srini@kernel.org>
|
||||
M: Amol Maheshwari <amahesh@qti.qualcomm.com>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
@@ -20451,8 +20671,8 @@ F: Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml
|
||||
F: drivers/i2c/busses/i2c-emev2.c
|
||||
|
||||
RENESAS ETHERNET AVB DRIVER
|
||||
M: Paul Barker <paul.barker.ct@bp.renesas.com>
|
||||
M: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
||||
R: Paul Barker <paul@pbarker.dev>
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
S: Maintained
|
||||
@@ -21253,6 +21473,7 @@ L: linux-s390@vger.kernel.org
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/s390/net/
|
||||
F: include/linux/ism.h
|
||||
|
||||
S390 PCI SUBSYSTEM
|
||||
M: Niklas Schnelle <schnelle@linux.ibm.com>
|
||||
@@ -21921,7 +22142,7 @@ S: Maintained
|
||||
F: drivers/media/rc/serial_ir.c
|
||||
|
||||
SERIAL LOW-POWER INTER-CHIP MEDIA BUS (SLIMbus)
|
||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
M: Srinivas Kandagatla <srini@kernel.org>
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/slimbus/
|
||||
@@ -22137,6 +22358,7 @@ F: drivers/platform/x86/touchscreen_dmi.c
|
||||
|
||||
SILICON LABS WIRELESS DRIVERS (for WFxxx series)
|
||||
M: Jérôme Pouiller <jerome.pouiller@silabs.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
|
||||
F: drivers/net/wireless/silabs/
|
||||
@@ -22237,9 +22459,7 @@ F: drivers/nvmem/layouts/sl28vpd.c
|
||||
|
||||
SLAB ALLOCATOR
|
||||
M: Christoph Lameter <cl@linux.com>
|
||||
M: Pekka Enberg <penberg@kernel.org>
|
||||
M: David Rientjes <rientjes@google.com>
|
||||
M: Joonsoo Kim <iamjoonsoo.kim@lge.com>
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
M: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Roman Gushchin <roman.gushchin@linux.dev>
|
||||
@@ -22654,9 +22874,15 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
|
||||
F: Documentation/devicetree/bindings/sound/
|
||||
F: Documentation/sound/soc/
|
||||
F: include/dt-bindings/sound/
|
||||
F: include/sound/cs-amp-lib.h
|
||||
F: include/sound/cs35l*
|
||||
F: include/sound/cs4271.h
|
||||
F: include/sound/cs42l*
|
||||
F: include/sound/madera-pdata.h
|
||||
F: include/sound/soc*
|
||||
F: include/sound/sof.h
|
||||
F: include/sound/sof/
|
||||
F: include/sound/wm*.h
|
||||
F: include/trace/events/sof*.h
|
||||
F: include/uapi/sound/asoc.h
|
||||
F: sound/soc/
|
||||
@@ -22767,7 +22993,6 @@ F: drivers/accessibility/speakup/
|
||||
|
||||
SPEAR PLATFORM/CLOCK/PINCTRL SUPPORT
|
||||
M: Viresh Kumar <vireshk@kernel.org>
|
||||
M: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: soc@lists.linux.dev
|
||||
S: Maintained
|
||||
@@ -25126,9 +25351,13 @@ S: Maintained
|
||||
F: drivers/usb/typec/mux/pi3usb30532.c
|
||||
|
||||
USB TYPEC PORT CONTROLLER DRIVERS
|
||||
M: Badhri Jagan Sridharan <badhri@google.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Orphan
|
||||
F: drivers/usb/typec/tcpm/
|
||||
S: Maintained
|
||||
F: drivers/usb/typec/tcpm/tcpci.c
|
||||
F: drivers/usb/typec/tcpm/tcpm.c
|
||||
F: include/linux/usb/tcpci.h
|
||||
F: include/linux/usb/tcpm.h
|
||||
|
||||
USB TYPEC TUSB1046 MUX DRIVER
|
||||
M: Romain Gantois <romain.gantois@bootlin.com>
|
||||
@@ -25741,7 +25970,7 @@ F: tools/testing/vsock/
|
||||
|
||||
VMALLOC
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
R: Uladzislau Rezki <urezki@gmail.com>
|
||||
M: Uladzislau Rezki <urezki@gmail.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
@@ -25765,7 +25994,7 @@ F: drivers/misc/vmw_balloon.c
|
||||
|
||||
VMWARE HYPERVISOR INTERFACE
|
||||
M: Ajay Kaher <ajay.kaher@broadcom.com>
|
||||
M: Alexey Makhalov <alexey.amakhalov@broadcom.com>
|
||||
M: Alexey Makhalov <alexey.makhalov@broadcom.com>
|
||||
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
|
||||
L: virtualization@lists.linux.dev
|
||||
L: x86@kernel.org
|
||||
@@ -25793,7 +26022,7 @@ F: drivers/scsi/vmw_pvscsi.h
|
||||
VMWARE VIRTUAL PTP CLOCK DRIVER
|
||||
M: Nick Shi <nick.shi@broadcom.com>
|
||||
R: Ajay Kaher <ajay.kaher@broadcom.com>
|
||||
R: Alexey Makhalov <alexey.amakhalov@broadcom.com>
|
||||
R: Alexey Makhalov <alexey.makhalov@broadcom.com>
|
||||
R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
13
Makefile
13
Makefile
@@ -2,7 +2,7 @@
|
||||
VERSION = 6
|
||||
PATCHLEVEL = 15
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION =
|
||||
NAME = Baby Opossum Posse
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@@ -477,7 +477,6 @@ export rust_common_flags := --edition=2021 \
|
||||
-Wclippy::ignored_unit_patterns \
|
||||
-Wclippy::mut_mut \
|
||||
-Wclippy::needless_bitwise_bool \
|
||||
-Wclippy::needless_continue \
|
||||
-Aclippy::needless_lifetimes \
|
||||
-Wclippy::no_mangle_with_rust_abi \
|
||||
-Wclippy::undocumented_unsafe_blocks \
|
||||
@@ -1053,10 +1052,6 @@ NOSTDINC_FLAGS += -nostdinc
|
||||
# perform bounds checking.
|
||||
KBUILD_CFLAGS += $(call cc-option, -fstrict-flex-arrays=3)
|
||||
|
||||
#Currently, disable -Wstringop-overflow for GCC 11, globally.
|
||||
KBUILD_CFLAGS-$(CONFIG_CC_NO_STRINGOP_OVERFLOW) += $(call cc-option, -Wno-stringop-overflow)
|
||||
KBUILD_CFLAGS-$(CONFIG_CC_STRINGOP_OVERFLOW) += $(call cc-option, -Wstringop-overflow)
|
||||
|
||||
# disable invalid "can't wrap" optimizations for signed / pointers
|
||||
KBUILD_CFLAGS += -fno-strict-overflow
|
||||
|
||||
@@ -1068,10 +1063,12 @@ ifdef CONFIG_CC_IS_GCC
|
||||
KBUILD_CFLAGS += -fconserve-stack
|
||||
endif
|
||||
|
||||
# Ensure compilers do not transform certain loops into calls to wcslen()
|
||||
KBUILD_CFLAGS += -fno-builtin-wcslen
|
||||
|
||||
# change __FILE__ to the relative path to the source directory
|
||||
ifdef building_out_of_srctree
|
||||
KBUILD_CPPFLAGS += $(call cc-option,-ffile-prefix-map=$(srcroot)/=)
|
||||
KBUILD_RUSTFLAGS += --remap-path-prefix=$(srcroot)/=
|
||||
KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srcroot)/=)
|
||||
endif
|
||||
|
||||
# include additional Makefiles when needed
|
||||
|
||||
@@ -451,7 +451,7 @@ analog_top: analog-top@81a8 {
|
||||
pwm_ef: pwm@86c0 {
|
||||
compatible = "amlogic,meson8-pwm-v2";
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
reg = <0x86c0 0x10>;
|
||||
@@ -705,7 +705,7 @@ timer@600 {
|
||||
&pwm_ab {
|
||||
compatible = "amlogic,meson8-pwm-v2";
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
@@ -713,7 +713,7 @@ &pwm_ab {
|
||||
&pwm_cd {
|
||||
compatible = "amlogic,meson8-pwm-v2";
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
|
||||
@@ -406,7 +406,7 @@ pwm_ef: pwm@86c0 {
|
||||
compatible = "amlogic,meson8b-pwm-v2", "amlogic,meson8-pwm-v2";
|
||||
reg = <0x86c0 0x10>;
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
#pwm-cells = <3>;
|
||||
@@ -680,7 +680,7 @@ timer@600 {
|
||||
&pwm_ab {
|
||||
compatible = "amlogic,meson8b-pwm-v2", "amlogic,meson8-pwm-v2";
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
@@ -688,7 +688,7 @@ &pwm_ab {
|
||||
&pwm_cd {
|
||||
compatible = "amlogic,meson8b-pwm-v2", "amlogic,meson8-pwm-v2";
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "Video PLL" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
|
||||
@@ -40,6 +40,9 @@ ethphy1: ethernet-phy@1 {
|
||||
reg = <1>;
|
||||
interrupt-parent = <&gpio4>;
|
||||
interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
|
||||
micrel,led-mode = <1>;
|
||||
clocks = <&clks IMX6UL_CLK_ENET_REF>;
|
||||
clock-names = "rmii-ref";
|
||||
status = "okay";
|
||||
};
|
||||
};
|
||||
|
||||
@@ -232,7 +232,6 @@ CONFIG_CRYPTO_USER_API_SKCIPHER=m
|
||||
CONFIG_CRYPTO_DEV_ATMEL_AES=y
|
||||
CONFIG_CRYPTO_DEV_ATMEL_TDES=y
|
||||
CONFIG_CRYPTO_DEV_ATMEL_SHA=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_FONTS=y
|
||||
CONFIG_FONT_8x8=y
|
||||
CONFIG_FONT_ACORN_8x8=y
|
||||
|
||||
@@ -78,7 +78,6 @@ CONFIG_ROMFS_FS=y
|
||||
CONFIG_NLS_DEFAULT="cp437"
|
||||
CONFIG_NLS_CODEPAGE_437=y
|
||||
CONFIG_NLS_ISO8859_1=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_FONTS=y
|
||||
CONFIG_FONT_MINI_4x6=y
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
|
||||
@@ -249,7 +249,6 @@ CONFIG_NLS_ASCII=m
|
||||
CONFIG_NLS_ISO8859_1=y
|
||||
CONFIG_NLS_UTF8=m
|
||||
# CONFIG_CRYPTO_HW is not set
|
||||
CONFIG_CRC_T10DIF=m
|
||||
CONFIG_DMA_CMA=y
|
||||
CONFIG_DEBUG_FS=y
|
||||
CONFIG_DEBUG_RT_MUTEXES=y
|
||||
|
||||
@@ -128,7 +128,6 @@ CONFIG_CRYPTO_DEFLATE=y
|
||||
CONFIG_CRYPTO_LZO=y
|
||||
# CONFIG_CRYPTO_ANSI_CPRNG is not set
|
||||
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
||||
@@ -370,7 +370,6 @@ CONFIG_CRYPTO_AES_ARM_BS=m
|
||||
CONFIG_CRYPTO_CHACHA20_NEON=m
|
||||
CONFIG_CRYPTO_DEV_EXYNOS_RNG=y
|
||||
CONFIG_CRYPTO_DEV_S5P=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_DMA_CMA=y
|
||||
CONFIG_CMA_SIZE_MBYTES=96
|
||||
CONFIG_FONTS=y
|
||||
|
||||
@@ -481,8 +481,6 @@ CONFIG_SECURITYFS=y
|
||||
CONFIG_CRYPTO_DEV_FSL_CAAM=y
|
||||
CONFIG_CRYPTO_DEV_SAHARA=y
|
||||
CONFIG_CRYPTO_DEV_MXS_DCP=y
|
||||
CONFIG_CRC_CCITT=m
|
||||
CONFIG_CRC_T10DIF=y
|
||||
CONFIG_CMA_SIZE_MBYTES=64
|
||||
CONFIG_FONTS=y
|
||||
CONFIG_FONT_8x8=y
|
||||
|
||||
@@ -147,7 +147,6 @@ CONFIG_EXT2_FS=y
|
||||
# CONFIG_INOTIFY_USER is not set
|
||||
CONFIG_JFFS2_FS=y
|
||||
# CONFIG_NETWORK_FILESYSTEMS is not set
|
||||
CONFIG_CRC_ITU_T=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
# CONFIG_ENABLE_MUST_CHECK is not set
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
|
||||
@@ -179,7 +179,6 @@ CONFIG_NLS_ISO8859_1=y
|
||||
CONFIG_NLS_UTF8=y
|
||||
CONFIG_CRYPTO_ANSI_CPRNG=y
|
||||
# CONFIG_CRYPTO_HW is not set
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
CONFIG_DYNAMIC_DEBUG=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
||||
@@ -108,8 +108,6 @@ CONFIG_CRYPTO_AES_ARM_BS=m
|
||||
CONFIG_CRYPTO_AES_ARM_CE=m
|
||||
CONFIG_CRYPTO_CHACHA20_NEON=m
|
||||
# CONFIG_CRYPTO_HW is not set
|
||||
CONFIG_CRC_CCITT=m
|
||||
CONFIG_CRC_ITU_T=m
|
||||
CONFIG_DMA_CMA=y
|
||||
CONFIG_CMA_SIZE_MBYTES=64
|
||||
CONFIG_PRINTK_TIME=y
|
||||
|
||||
@@ -67,7 +67,6 @@ CONFIG_NFS_V3=y
|
||||
CONFIG_NFS_V3_ACL=y
|
||||
CONFIG_NFS_V4=y
|
||||
CONFIG_ROOT_NFS=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
||||
@@ -91,6 +91,5 @@ CONFIG_MSDOS_FS=y
|
||||
CONFIG_VFAT_FS=y
|
||||
CONFIG_CRAMFS=y
|
||||
CONFIG_MINIX_FS=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
# CONFIG_FTRACE is not set
|
||||
CONFIG_DEBUG_USER=y
|
||||
|
||||
@@ -289,7 +289,6 @@ CONFIG_NLS_UTF8=y
|
||||
CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
|
||||
@@ -187,7 +187,6 @@ CONFIG_NLS_UTF8=y
|
||||
CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
|
||||
@@ -160,7 +160,6 @@ CONFIG_NLS_CODEPAGE_850=y
|
||||
CONFIG_NLS_ISO8859_1=y
|
||||
CONFIG_NLS_ISO8859_15=y
|
||||
CONFIG_CRYPTO_DEV_MXS_DCP=y
|
||||
CONFIG_CRC_ITU_T=m
|
||||
CONFIG_FONTS=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
|
||||
@@ -706,9 +706,6 @@ CONFIG_CRYPTO_DEV_OMAP=m
|
||||
CONFIG_CRYPTO_DEV_OMAP_SHAM=m
|
||||
CONFIG_CRYPTO_DEV_OMAP_AES=m
|
||||
CONFIG_CRYPTO_DEV_OMAP_DES=m
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_CRC_T10DIF=y
|
||||
CONFIG_CRC_ITU_T=y
|
||||
CONFIG_DMA_CMA=y
|
||||
CONFIG_FONTS=y
|
||||
CONFIG_FONT_8x8=y
|
||||
|
||||
@@ -136,7 +136,6 @@ CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_ECB=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
|
||||
CONFIG_CRC_T10DIF=y
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
|
||||
@@ -41,7 +41,6 @@ CONFIG_NFS_V3=y
|
||||
CONFIG_NFS_V3_ACL=y
|
||||
CONFIG_NFS_V4=y
|
||||
CONFIG_ROOT_NFS=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
||||
@@ -50,7 +50,6 @@ CONFIG_NFS_V3=y
|
||||
CONFIG_NFS_V3_ACL=y
|
||||
CONFIG_NFS_V4=y
|
||||
CONFIG_ROOT_NFS=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
||||
@@ -663,8 +663,6 @@ CONFIG_CRYPTO_SHA1_ARM=m
|
||||
CONFIG_CRYPTO_SHA256_ARM=m
|
||||
CONFIG_CRYPTO_SHA512_ARM=m
|
||||
CONFIG_CRYPTO_AES_ARM=m
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_CRC_T10DIF=m
|
||||
CONFIG_FONTS=y
|
||||
CONFIG_FONT_8x8=y
|
||||
CONFIG_FONT_8x16=y
|
||||
|
||||
@@ -113,7 +113,6 @@ CONFIG_NLS_CODEPAGE_437=y
|
||||
CONFIG_NLS_ASCII=y
|
||||
CONFIG_NLS_ISO8859_1=y
|
||||
CONFIG_NLS_UTF8=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
|
||||
@@ -227,8 +227,6 @@ CONFIG_CRYPTO_USER_API_SKCIPHER=m
|
||||
CONFIG_CRYPTO_DEV_ATMEL_AES=y
|
||||
CONFIG_CRYPTO_DEV_ATMEL_TDES=y
|
||||
CONFIG_CRYPTO_DEV_ATMEL_SHA=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_CRC_ITU_T=y
|
||||
CONFIG_DMA_CMA=y
|
||||
CONFIG_CMA_SIZE_MBYTES=32
|
||||
CONFIG_CMA_ALIGNMENT=9
|
||||
|
||||
@@ -234,7 +234,6 @@ CONFIG_CRYPTO_MD4=m
|
||||
CONFIG_CRYPTO_MICHAEL_MIC=m
|
||||
CONFIG_CRYPTO_SHA512=m
|
||||
CONFIG_CRYPTO_WP512=m
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_FONTS=y
|
||||
CONFIG_FONT_8x8=y
|
||||
CONFIG_FONT_8x16=y
|
||||
|
||||
@@ -74,7 +74,6 @@ CONFIG_EXT3_FS=y
|
||||
# CONFIG_DNOTIFY is not set
|
||||
# CONFIG_INOTIFY_USER is not set
|
||||
CONFIG_NLS=y
|
||||
CONFIG_CRC_ITU_T=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
||||
@@ -191,8 +191,6 @@ CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
|
||||
CONFIG_X509_CERTIFICATE_PARSER=y
|
||||
CONFIG_PKCS7_MESSAGE_PARSER=y
|
||||
CONFIG_SYSTEM_TRUSTED_KEYRING=y
|
||||
CONFIG_CRC_CCITT=y
|
||||
CONFIG_CRC_ITU_T=m
|
||||
CONFIG_PRINTK_TIME=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
|
||||
@@ -152,28 +152,12 @@ &pio {
|
||||
vcc-pg-supply = <®_aldo1>;
|
||||
};
|
||||
|
||||
&r_ir {
|
||||
linux,rc-map-name = "rc-beelink-gs1";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&r_pio {
|
||||
/*
|
||||
* FIXME: We can't add that supply for now since it would
|
||||
* create a circular dependency between pinctrl, the regulator
|
||||
* and the RSB Bus.
|
||||
*
|
||||
* vcc-pl-supply = <®_aldo1>;
|
||||
*/
|
||||
vcc-pm-supply = <®_aldo1>;
|
||||
};
|
||||
|
||||
&r_rsb {
|
||||
&r_i2c {
|
||||
status = "okay";
|
||||
|
||||
axp805: pmic@745 {
|
||||
axp805: pmic@36 {
|
||||
compatible = "x-powers,axp805", "x-powers,axp806";
|
||||
reg = <0x745>;
|
||||
reg = <0x36>;
|
||||
interrupt-parent = <&r_intc>;
|
||||
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
@@ -291,6 +275,22 @@ sw {
|
||||
};
|
||||
};
|
||||
|
||||
&r_ir {
|
||||
linux,rc-map-name = "rc-beelink-gs1";
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&r_pio {
|
||||
/*
|
||||
* PL0 and PL1 are used for PMIC I2C
|
||||
* don't enable the pl-supply else
|
||||
* it will fail at boot
|
||||
*
|
||||
* vcc-pl-supply = <®_aldo1>;
|
||||
*/
|
||||
vcc-pm-supply = <®_aldo1>;
|
||||
};
|
||||
|
||||
&spdif {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&spdif_tx_pin>;
|
||||
|
||||
@@ -176,16 +176,12 @@ &pio {
|
||||
vcc-pg-supply = <®_vcc_wifi_io>;
|
||||
};
|
||||
|
||||
&r_ir {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&r_rsb {
|
||||
&r_i2c {
|
||||
status = "okay";
|
||||
|
||||
axp805: pmic@745 {
|
||||
axp805: pmic@36 {
|
||||
compatible = "x-powers,axp805", "x-powers,axp806";
|
||||
reg = <0x745>;
|
||||
reg = <0x36>;
|
||||
interrupt-parent = <&r_intc>;
|
||||
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
@@ -296,6 +292,10 @@ sw {
|
||||
};
|
||||
};
|
||||
|
||||
&r_ir {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&rtc {
|
||||
clocks = <&ext_osc32k>;
|
||||
};
|
||||
|
||||
@@ -113,20 +113,12 @@ &pio {
|
||||
vcc-pg-supply = <®_aldo1>;
|
||||
};
|
||||
|
||||
&r_ir {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&r_pio {
|
||||
vcc-pm-supply = <®_bldo3>;
|
||||
};
|
||||
|
||||
&r_rsb {
|
||||
&r_i2c {
|
||||
status = "okay";
|
||||
|
||||
axp805: pmic@745 {
|
||||
axp805: pmic@36 {
|
||||
compatible = "x-powers,axp805", "x-powers,axp806";
|
||||
reg = <0x745>;
|
||||
reg = <0x36>;
|
||||
interrupt-parent = <&r_intc>;
|
||||
interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
@@ -241,6 +233,14 @@ sw {
|
||||
};
|
||||
};
|
||||
|
||||
&r_ir {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&r_pio {
|
||||
vcc-pm-supply = <®_bldo3>;
|
||||
};
|
||||
|
||||
&rtc {
|
||||
clocks = <&ext_osc32k>;
|
||||
};
|
||||
|
||||
@@ -151,7 +151,7 @@ msix: msix@fbe00000 {
|
||||
al,msi-num-spis = <160>;
|
||||
};
|
||||
|
||||
io-fabric@fc000000 {
|
||||
io-bus@fc000000 {
|
||||
compatible = "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
@@ -361,7 +361,7 @@ msix: msix@fbe00000 {
|
||||
interrupt-parent = <&gic>;
|
||||
};
|
||||
|
||||
io-fabric@fc000000 {
|
||||
io-bus@fc000000 {
|
||||
compatible = "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
@@ -2313,7 +2313,7 @@ pwm_ef: pwm@19000 {
|
||||
"amlogic,meson8-pwm-v2";
|
||||
reg = <0x0 0x19000 0x0 0x20>;
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
#pwm-cells = <3>;
|
||||
@@ -2325,7 +2325,7 @@ pwm_cd: pwm@1a000 {
|
||||
"amlogic,meson8-pwm-v2";
|
||||
reg = <0x0 0x1a000 0x0 0x20>;
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
#pwm-cells = <3>;
|
||||
@@ -2337,7 +2337,7 @@ pwm_ab: pwm@1b000 {
|
||||
"amlogic,meson8-pwm-v2";
|
||||
reg = <0x0 0x1b000 0x0 0x20>;
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
#pwm-cells = <3>;
|
||||
|
||||
@@ -116,6 +116,10 @@ &arb {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&clkc_audio {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&frddr_a {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@@ -741,7 +741,7 @@ mux {
|
||||
|
||||
&pwm_ab {
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
@@ -752,14 +752,14 @@ &pwm_AO_ab {
|
||||
|
||||
&pwm_cd {
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
|
||||
&pwm_ef {
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
|
||||
@@ -811,7 +811,7 @@ internal_phy: ethernet-phy@8 {
|
||||
|
||||
&pwm_ab {
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
@@ -822,14 +822,14 @@ &pwm_AO_ab {
|
||||
|
||||
&pwm_cd {
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
|
||||
&pwm_ef {
|
||||
clocks = <&xtal>,
|
||||
<>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<0>, /* unknown/untested, the datasheet calls it "vid_pll" */
|
||||
<&clkc CLKID_FCLK_DIV4>,
|
||||
<&clkc CLKID_FCLK_DIV3>;
|
||||
};
|
||||
|
||||
@@ -77,6 +77,16 @@ touchbar0: touchbar@0 {
|
||||
};
|
||||
};
|
||||
|
||||
/*
|
||||
* The driver depends on boot loader initialized state which resets when this
|
||||
* power-domain is powered off. This happens on suspend or when the driver is
|
||||
* missing during boot. Mark the domain as always on until the driver can
|
||||
* handle this.
|
||||
*/
|
||||
&ps_dispdfr_be {
|
||||
apple,always-on;
|
||||
};
|
||||
|
||||
&display_dfr {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@@ -40,6 +40,16 @@ led-0 {
|
||||
};
|
||||
};
|
||||
|
||||
/*
|
||||
* The driver depends on boot loader initialized state which resets when this
|
||||
* power-domain is powered off. This happens on suspend or when the driver is
|
||||
* missing during boot. Mark the domain as always on until the driver can
|
||||
* handle this.
|
||||
*/
|
||||
&ps_dispdfr_be {
|
||||
apple,always-on;
|
||||
};
|
||||
|
||||
&display_dfr {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@@ -44,7 +44,7 @@ cpu0: cpu@0 {
|
||||
next-level-cache = <&l2_0>;
|
||||
clocks = <&scmi_dvfs 0>;
|
||||
|
||||
l2_0: l2-cache-0 {
|
||||
l2_0: l2-cache {
|
||||
compatible = "cache";
|
||||
cache-level = <2>;
|
||||
/* 8 ways set associative */
|
||||
@@ -53,13 +53,6 @@ l2_0: l2-cache-0 {
|
||||
cache-sets = <2048>;
|
||||
cache-unified;
|
||||
next-level-cache = <&l3_0>;
|
||||
|
||||
l3_0: l3-cache {
|
||||
compatible = "cache";
|
||||
cache-level = <3>;
|
||||
cache-size = <0x100000>;
|
||||
cache-unified;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -78,7 +71,7 @@ cpu1: cpu@100 {
|
||||
next-level-cache = <&l2_1>;
|
||||
clocks = <&scmi_dvfs 0>;
|
||||
|
||||
l2_1: l2-cache-1 {
|
||||
l2_1: l2-cache {
|
||||
compatible = "cache";
|
||||
cache-level = <2>;
|
||||
/* 8 ways set associative */
|
||||
@@ -105,7 +98,7 @@ cpu2: cpu@10000 {
|
||||
next-level-cache = <&l2_2>;
|
||||
clocks = <&scmi_dvfs 1>;
|
||||
|
||||
l2_2: l2-cache-2 {
|
||||
l2_2: l2-cache {
|
||||
compatible = "cache";
|
||||
cache-level = <2>;
|
||||
/* 8 ways set associative */
|
||||
@@ -132,7 +125,7 @@ cpu3: cpu@10100 {
|
||||
next-level-cache = <&l2_3>;
|
||||
clocks = <&scmi_dvfs 1>;
|
||||
|
||||
l2_3: l2-cache-3 {
|
||||
l2_3: l2-cache {
|
||||
compatible = "cache";
|
||||
cache-level = <2>;
|
||||
/* 8 ways set associative */
|
||||
@@ -143,6 +136,13 @@ l2_3: l2-cache-3 {
|
||||
next-level-cache = <&l3_0>;
|
||||
};
|
||||
};
|
||||
|
||||
l3_0: l3-cache {
|
||||
compatible = "cache";
|
||||
cache-level = <3>;
|
||||
cache-size = <0x100000>;
|
||||
cache-unified;
|
||||
};
|
||||
};
|
||||
|
||||
firmware {
|
||||
|
||||
@@ -144,6 +144,19 @@ reg_usdhc2_vmmc: regulator-usdhc2 {
|
||||
startup-delay-us = <20000>;
|
||||
};
|
||||
|
||||
reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
|
||||
compatible = "regulator-gpio";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_usdhc2_vsel>;
|
||||
gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-min-microvolt = <1800000>;
|
||||
states = <1800000 0x1>,
|
||||
<3300000 0x0>;
|
||||
regulator-name = "PMIC_USDHC_VSELECT";
|
||||
vin-supply = <®_nvcc_sd>;
|
||||
};
|
||||
|
||||
reserved-memory {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
@@ -269,7 +282,7 @@ &gpio1 {
|
||||
"SODIMM_19",
|
||||
"",
|
||||
"",
|
||||
"",
|
||||
"PMIC_USDHC_VSELECT",
|
||||
"",
|
||||
"",
|
||||
"",
|
||||
@@ -785,6 +798,7 @@ &usdhc2 {
|
||||
pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_cd>;
|
||||
pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_cd_sleep>;
|
||||
vmmc-supply = <®_usdhc2_vmmc>;
|
||||
vqmmc-supply = <®_usdhc2_vqmmc>;
|
||||
};
|
||||
|
||||
&wdog1 {
|
||||
@@ -1206,13 +1220,17 @@ pinctrl_usdhc2_pwr_en: usdhc2pwrengrp {
|
||||
<MX8MM_IOMUXC_NAND_CLE_GPIO3_IO5 0x6>; /* SODIMM 76 */
|
||||
};
|
||||
|
||||
pinctrl_usdhc2_vsel: usdhc2vselgrp {
|
||||
fsl,pins =
|
||||
<MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4 0x10>; /* PMIC_USDHC_VSELECT */
|
||||
};
|
||||
|
||||
/*
|
||||
* Note: Due to ERR050080 we use discrete external on-module resistors pulling-up to the
|
||||
* on-module +V3.3_1.8_SD (LDO5) rail and explicitly disable the internal pull-ups here.
|
||||
*/
|
||||
pinctrl_usdhc2: usdhc2grp {
|
||||
fsl,pins =
|
||||
<MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x10>,
|
||||
<MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x90>, /* SODIMM 78 */
|
||||
<MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x90>, /* SODIMM 74 */
|
||||
<MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x90>, /* SODIMM 80 */
|
||||
@@ -1223,7 +1241,6 @@ pinctrl_usdhc2: usdhc2grp {
|
||||
|
||||
pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
|
||||
fsl,pins =
|
||||
<MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x10>,
|
||||
<MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x94>,
|
||||
<MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x94>,
|
||||
<MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x94>,
|
||||
@@ -1234,7 +1251,6 @@ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
|
||||
|
||||
pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
|
||||
fsl,pins =
|
||||
<MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x10>,
|
||||
<MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x96>,
|
||||
<MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x96>,
|
||||
<MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x96>,
|
||||
@@ -1246,7 +1262,6 @@ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
|
||||
/* Avoid backfeeding with removed card power */
|
||||
pinctrl_usdhc2_sleep: usdhc2slpgrp {
|
||||
fsl,pins =
|
||||
<MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x0>,
|
||||
<MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x0>,
|
||||
<MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x0>,
|
||||
<MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x0>,
|
||||
|
||||
@@ -24,6 +24,20 @@ &clk {
|
||||
fsl,operating-mode = "nominal";
|
||||
};
|
||||
|
||||
&gpu2d {
|
||||
assigned-clocks = <&clk IMX8MP_CLK_GPU2D_CORE>;
|
||||
assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_800M>;
|
||||
assigned-clock-rates = <800000000>;
|
||||
};
|
||||
|
||||
&gpu3d {
|
||||
assigned-clocks = <&clk IMX8MP_CLK_GPU3D_CORE>,
|
||||
<&clk IMX8MP_CLK_GPU3D_SHADER_CORE>;
|
||||
assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_800M>,
|
||||
<&clk IMX8MP_SYS_PLL1_800M>;
|
||||
assigned-clock-rates = <800000000>, <800000000>;
|
||||
};
|
||||
|
||||
&pgc_hdmimix {
|
||||
assigned-clocks = <&clk IMX8MP_CLK_HDMI_AXI>,
|
||||
<&clk IMX8MP_CLK_HDMI_APB>;
|
||||
@@ -46,6 +60,18 @@ &pgc_gpumix {
|
||||
assigned-clock-rates = <600000000>, <300000000>;
|
||||
};
|
||||
|
||||
&pgc_mlmix {
|
||||
assigned-clocks = <&clk IMX8MP_CLK_ML_CORE>,
|
||||
<&clk IMX8MP_CLK_ML_AXI>,
|
||||
<&clk IMX8MP_CLK_ML_AHB>;
|
||||
assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_800M>,
|
||||
<&clk IMX8MP_SYS_PLL1_800M>,
|
||||
<&clk IMX8MP_SYS_PLL1_800M>;
|
||||
assigned-clock-rates = <800000000>,
|
||||
<800000000>,
|
||||
<300000000>;
|
||||
};
|
||||
|
||||
&media_blk_ctrl {
|
||||
assigned-clocks = <&clk IMX8MP_CLK_MEDIA_AXI>,
|
||||
<&clk IMX8MP_CLK_MEDIA_APB>,
|
||||
@@ -62,3 +88,5 @@ &media_blk_ctrl {
|
||||
<0>, <0>, <400000000>,
|
||||
<1039500000>;
|
||||
};
|
||||
|
||||
/delete-node/ &{noc_opp_table/opp-1000000000};
|
||||
|
||||
@@ -35,7 +35,6 @@ memory@40000000 {
|
||||
<0x1 0x00000000 0 0xc0000000>;
|
||||
};
|
||||
|
||||
|
||||
reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
|
||||
compatible = "regulator-fixed";
|
||||
regulator-name = "VSD_3V3";
|
||||
@@ -46,6 +45,16 @@ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
|
||||
startup-delay-us = <100>;
|
||||
off-on-delay-us = <12000>;
|
||||
};
|
||||
|
||||
reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
|
||||
compatible = "regulator-gpio";
|
||||
regulator-name = "VSD_VSEL";
|
||||
regulator-min-microvolt = <1800000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
gpios = <&gpio2 12 GPIO_ACTIVE_HIGH>;
|
||||
states = <3300000 0x0 1800000 0x1>;
|
||||
vin-supply = <&ldo5>;
|
||||
};
|
||||
};
|
||||
|
||||
&A53_0 {
|
||||
@@ -205,6 +214,7 @@ &usdhc2 {
|
||||
pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
|
||||
cd-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
|
||||
vmmc-supply = <®_usdhc2_vmmc>;
|
||||
vqmmc-supply = <®_usdhc2_vqmmc>;
|
||||
bus-width = <4>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@@ -1645,6 +1645,12 @@ opp-200000000 {
|
||||
opp-hz = /bits/ 64 <200000000>;
|
||||
};
|
||||
|
||||
/* Nominal drive mode maximum */
|
||||
opp-800000000 {
|
||||
opp-hz = /bits/ 64 <800000000>;
|
||||
};
|
||||
|
||||
/* Overdrive mode maximum */
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
};
|
||||
|
||||
@@ -1626,7 +1626,7 @@ pcie0: pcie@4c300000 {
|
||||
reg = <0 0x4c300000 0 0x10000>,
|
||||
<0 0x60100000 0 0xfe00000>,
|
||||
<0 0x4c360000 0 0x10000>,
|
||||
<0 0x4c340000 0 0x2000>;
|
||||
<0 0x4c340000 0 0x4000>;
|
||||
reg-names = "dbi", "config", "atu", "app";
|
||||
ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
|
||||
<0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
|
||||
@@ -1673,7 +1673,7 @@ pcie0_ep: pcie-ep@4c300000 {
|
||||
reg = <0 0x4c300000 0 0x10000>,
|
||||
<0 0x4c360000 0 0x1000>,
|
||||
<0 0x4c320000 0 0x1000>,
|
||||
<0 0x4c340000 0 0x2000>,
|
||||
<0 0x4c340000 0 0x4000>,
|
||||
<0 0x4c370000 0 0x10000>,
|
||||
<0x9 0 1 0>;
|
||||
reg-names = "dbi","atu", "dbi2", "app", "dma", "addr_space";
|
||||
@@ -1700,7 +1700,7 @@ pcie1: pcie@4c380000 {
|
||||
reg = <0 0x4c380000 0 0x10000>,
|
||||
<8 0x80100000 0 0xfe00000>,
|
||||
<0 0x4c3e0000 0 0x10000>,
|
||||
<0 0x4c3c0000 0 0x2000>;
|
||||
<0 0x4c3c0000 0 0x4000>;
|
||||
reg-names = "dbi", "config", "atu", "app";
|
||||
ranges = <0x81000000 0 0x00000000 0x8 0x8ff00000 0 0x00100000>,
|
||||
<0x82000000 0 0x10000000 0xa 0x10000000 0 0x10000000>;
|
||||
@@ -1749,7 +1749,7 @@ pcie1_ep: pcie-ep@4c380000 {
|
||||
reg = <0 0x4c380000 0 0x10000>,
|
||||
<0 0x4c3e0000 0 0x1000>,
|
||||
<0 0x4c3a0000 0 0x1000>,
|
||||
<0 0x4c3c0000 0 0x2000>,
|
||||
<0 0x4c3c0000 0 0x4000>,
|
||||
<0 0x4c3f0000 0 0x10000>,
|
||||
<0xa 0 1 0>;
|
||||
reg-names = "dbi", "atu", "dbi2", "app", "dma", "addr_space";
|
||||
|
||||
@@ -26,6 +26,8 @@ memory@0 {
|
||||
|
||||
leds {
|
||||
compatible = "gpio-leds";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&spi_quad_pins>;
|
||||
|
||||
led-power1 {
|
||||
label = "udpu:green:power";
|
||||
@@ -82,8 +84,6 @@ &sdhci0 {
|
||||
|
||||
&spi0 {
|
||||
status = "okay";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&spi_quad_pins>;
|
||||
|
||||
flash@0 {
|
||||
compatible = "jedec,spi-nor";
|
||||
@@ -108,6 +108,10 @@ partition@180000 {
|
||||
};
|
||||
};
|
||||
|
||||
&spi_quad_pins {
|
||||
function = "gpio";
|
||||
};
|
||||
|
||||
&pinctrl_nb {
|
||||
i2c2_recovery_pins: i2c2-recovery-pins {
|
||||
groups = "i2c2";
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user