Add support for 800Gbps speed, link modes of 100Gbps per lane.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support for 800Gbps speed, link modes of 100Gbps per lane.
As mentioned in slide 21 in IEEE documentation [1], all adopted 802.3df
copper and optical PMDs baselines using 100G/lane will be supported.
Add the relevant PMDs which are mentioned in slide 5 in IEEE
documentation [1] and were approved on 10-2022 [2]:
BP - KR8
Cu Cable - CR8
MMF 50m - VR8
MMF 100m - SR8
SMF 500m - DR8
SMF 2km - DR8-2
[1]: https://www.ieee802.org/3/df/public/22_10/22_1004/shrikhande_3df_01a_221004.pdf
[2]: https://ieee802.org/3/df/KeyMotions_3df_221005.pdf
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add Raptor Lake client parts (both RPL and RPL_S) support to pmc core
driver. Raptor Lake client parts reuse all the Alder Lake PCH IPs.
Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: David Box <david.e.box@intel.com>
Acked-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela@linux.intel.com>
Link: https://lore.kernel.org/r/20220912233307.409954-2-gayatri.kammela@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Steen Hegelund says:
====================
Add support for Sparx5 IS2 VCAP
This provides initial support for the Sparx5 VCAP functionality via the
'tc' traffic control userspace tool and its flower filter.
Overview:
=========
The supported flower filter keys and actions are:
- source and destination MAC address keys
- trap action
- pass action
The supported Sparx5 VCAPs are: IS2 (see below for more info)
The VCAP (Versatile Content-Aware Processor) feature is essentially a TCAM
with rules consisting of:
- Programmable key fields
- Programmable action fields
- A counter (which may be only one bit wide)
Besides this each VCAP has:
- A number of independent lookups
- A keyset configuration typically per port per lookup
VCAPs are used in many of the TSN features such as PSFP, PTP, FRER as well
as the general shaping, policing and access control, so it is an important
building block for these advanced features.
Functionality:
==============
When a frame is passed to a VCAP the VCAP will generate a set of keys
(keyset) based on the traffic type. If there is a rule created with this
keyset in the VCAP and the values of the keys matches the values in the
keyset of the frame, the rule is said to match and the actions in the rule
will be executed and the rule counter will be incremented. No more rules
will be examined in this VCAP lookup.
If there is no match in the current lookup the frame will be matched
against the next lookup (some VCAPs do the processing of the lookups in
parallel).
The Sparx5 SoC has 6 different VCAP types:
- IS0: Ingress Stage 0 (AKA CLM) mostly handles classification
- IS2: Ingress Stage 2 mostly handles access control
- IP6PFX: IPv6 prefix: Provides tables for IPV6 address management
- LPM: Longest Path Match for IP guarding and routing
- ES0: Egress Stage 0 is mostly used for CPU copying and multicast handling
- ES2: Egress Stage 2 is known as the rewriter and mostly updates tags
Design:
=======
The VCAP implementation provides switchcore independent handling of rules
and supports:
- Creating and deleting rules
- Updating and getting rules
The platform specific API implementation as well as the platform specific
model of the VCAP instances are attached to the VCAP API and a client can
then access rules via the API in a platform independent way, with the
limitations that each VCAP has in terms of is supported keys and actions.
The VCAP model is generated from information delivered by the designers of
the VCAP hardware.
Here is an illustration of this:
+------------------+ +------------------+
| TC flower filter | | PTP client |
| for Sparx5 | | for Sparx5 |
+-------------\----+ +---------/--------+
\ /
\ /
\ /
\ /
\ /
+----v--------v----+
| VCAP API |
+---------|--------+
|
|
|
|
+---------v--------+
| VCAP control |
| instance |
+----/--------|----+
/ |
/ |
/ |
/ |
+--------------v---+ +----v-------------+
| Sparx5 VCAP | | Sparx5 VCAP API |
| model | | Implementation |
+------------------+ +---------|--------+
|
|
|
|
+---------v--------+
| Sparx5 VCAP HW |
+------------------+
Delivery:
=========
For now only the IS2 is supported but later the IS0, ES0 and ES2 will be
added. There are currently no plans to support the IP6PFX and the LPM
VCAPs.
The IS2 VCAP has 4 lookups and they are accessible with a TC chain id:
- chain 8000000: IS2 Lookup 0
- chain 8100000: IS2 Lookup 1
- chain 8200000: IS2 Lookup 2
- chain 8300000: IS2 Lookup 3
These lookups are executed in parallel by the IS2 VCAP but the actions are
executed in series (the datasheet explains what happens if actions
overlap).
The functionality of TC flower as well as TC matchall filters will be
expanded in later submissions as well as the number of VCAPs supported.
This is current plan:
- add support for more TC flower filter keys and extend the Sparx5 port
keyset configuration
- support for TC protocol all
- debugfs support for inspecting rules
- TC flower filter statistics
- Sparx5 IS0 VCAP support and more TC keys and actions to support this
- add TC policer and drop action support (depends on the Sparx5 QoS support
upstreamed separately)
- Sparx5 ES0 VCAP support and more TC actions to support this
- TC flower template support
- TC matchall filter support for mirroring and policing ports
- TC flower filter mirror action support
- Sparx5 ES2 VCAP support
The LAN966x switchcore will also be updated to use the VCAP API as well as
future Microchip switches.
The LAN966x has 3 VCAPS (IS1, IS2 and ES0) and a slightly different keyset
and actionset portfolio than Sparx5.
Version History:
================
v3 Moved the sparx5_tc_flower_set_exterr function to the VCAP API and
renamed it.
Moved the sparx5_netbytes_copy function to the VCAP_API and renamed
it (thanks Horatiu Vultur).
Fixed indentation in the vcap_write_rule function.
Added a comment mentioning the typegroup table terminator in the
vcap_iter_skip_tg function.
v2 Made the KUNIT test model a superset of the real model to fix a
kernel robot build error.
v1 Initial version
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This provides a KUNIT test suite for the VCAP APIs encoding functionality.
The test can be run by adding these settings in a .kunitconfig file
CONFIG_KUNIT=y
CONFIG_NET=y
CONFIG_VCAP_KUNIT_TEST=y
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This provides a test VCAP model for use in a KUNIT test. The model
provides 3 different VCAP types for better test coverage.
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds rule encoding functionality to the VCAP API.
A rule consists of keys and actions in separate cache sections.
The maximum size of the keyset or actionset determines the size of the
rule.
The VCAP hardware need to be able to distinguish different rule sizes from
each other, and for that purpose some extra typegroup bits are added to the
rule when it is encoded.
The API provides a bit stream iterator that allows highlevel encoding
functionality to add key and action value bits independent of typegroup
bits.
This is handled by letting the concrete VCAP model provide the typegroup
table for the different rule sizes.
After the key and action values have been added to the encoding bit streams
the typegroup bits are set to their correct values just before the rule is
written to the VCAP hardware.
The key and action offsets provided in the VCAP model are the offset before
adding the typegroup bits.
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Tested-by: Casper Andersson <casper.casan@gmail.com>
Reviewed-by: Casper Andersson <casper.casan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This provides most of the rule handling needed to add a new rule to a VCAP.
To add a rule a client must follow these steps:
1) Allocate a new rule (provide an id or get one automatically assigned)
2) Add keys to the rule
3) Add actions to the rule
4) Optionally set a keyset on the rule
5) Optionally set an actionset on the rule
6) Validate the rule (this will add keyset and actionset if not specified
in the previous steps)
7) Add the rule (if the validation was successful)
8) Free the rule instance (a copy has been added to the VCAP)
The validation step will fail if there are no keysets with the requested
keys, or there are no actionsets with the requested actions.
The validation will also fail if the keyset is not configured for the port
for the requested protocol).
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Tested-by: Casper Andersson <casper.casan@gmail.com>
Reviewed-by: Casper Andersson <casper.casan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This provides a default port keyset configuration for the Sparx5 IS2 VCAP
where all ports and all lookups in IS2 use the same keyset (MAC_ETYPE) for
all types of traffic.
This means that no matter what frame type is received on any front port it
will generate the MAC_ETYPE keyset in the IS VCAP and any rule in the IS2
VCAP that uses this keyset will be matched against the keys in the
MAC_ETYPE keyset.
The callback interface used by the VCAP API is populated with Sparx5
specific handler functions that takes care of the actual reading and
writing to data to the Sparx5 IS2 VCAP instance.
A few functions are also added to the VCAP API to support addition of rule
fields such as the ingress port mask and the lookup bit.
The IS2 VCAP in Sparx5 is really divided in two instances with lookup 0
and 1 in the first instance and lookup 2 and 3 in the second instance.
The lookup bit selects lookup 0 or 3 in the respective instance when it is
set.
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Tested-by: Casper Andersson <casper.casan@gmail.com>
Reviewed-by: Casper Andersson <casper.casan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds initial TC flower filter support to Sparx5 for the IS2 VCAP.
The support consists of the source and destination MAC addresses,
and the trap and pass actions.
This is how you can create a rule that test the functionality:
tc qdisc add dev eth0 clsact
tc filter add dev eth0 ingress chain 8000000 prio 10 handle 10 \
protocol all flower skip_sw \
dst_mac 0a:0b:0c:0d:0e:0f \
src_mac 2:0:0:0:0:1 \
action trap
The IS2 chains in Sparx5 are assigned like this:
- chain 8000000: IS2 Lookup 0
- chain 8100000: IS2 Lookup 1
- chain 8200000: IS2 Lookup 2
- chain 8300000: IS2 Lookup 3
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Tested-by: Casper Andersson <casper.casan@gmail.com>
Reviewed-by: Casper Andersson <casper.casan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds the register interface needed to access the Sparx5 Ingress Stage
2 VCAP (IS2).
The Sparx5 Chip Register Model can be browsed at this location:
https://github.com/microchip-ung/sparx-5_reginfo
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This provides the Sparx5 Ingress Stage 2 (IS2) model and adds it to the
VCAP control instance that will be provided to the VCAP API.
The Sparx5 IS2 C code model is generated from the Sparx5 RTL design model.
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This provides the initial VCAP API framework and Sparx5 specific VCAP
implementation.
When the Sparx5 Switchdev driver is initialized it will also initialize its
VCAP module, and this hooks up the concrete Sparx5 VCAP model to the VCAP
API, so that the VCAP API knows what VCAP instances are available.
Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Support hardware offload when tunnel neigh out port is bond.
These feature work with the nfp firmware. If the firmware
supports the NFP_FL_FEATS_TUNNEL_NEIGH_LAG feature, nfp driver
write the bond information to the firmware neighbor table or
do nothing for bond. when neighbor MAC changes, nfp driver
need to update the neighbor information too.
Signed-off-by: Yanguo Li <yanguo.li@corigine.com>
Reviewed-by: Louis Peens <louis.peens@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For apollolake the mapping between LEDs and GPIO pins was off because of
a refactoring when we introduced a new device model.
In addition to the reordering the indices in the lookup table need to be
updated as well.
Fixes: a97126265d ("leds: simatic-ipc-leds-gpio: add new model 227G")
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20221024092027.4529-1-henning.schild@siemens.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
There is a few things done:
- include only the headers we are direct user of
- when pointer is in use, provide a forward declaration
- add missing headers
- group generic headers and subsystem headers
- sort each group alphabetically
While at it, fix some awkward indentations.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Rewiewed-by: Kent Gibson <warthog618@gmail.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Some of the headers are unused in the driver, remove them.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The mlx5e_macsec_cleanup() routine has NULL pointer dereferencing if mlx5
device doesn't support MACsec (priv->macsec will be NULL).
While at it delete comment line, assignment and extra blank lines, so fix
everything in one patch.
Fixes: 1f53da6764 ("net/mlx5e: Create advanced steering operation (ASO) object for MACsec")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
commit b0c07116c8 ("platform/x86: amd-pmc: Avoid reading SMU version at
probe time") adjusted the behavior for amd-pmc to avoid reading the SMU
version at startup but rather on first use to improve boot time.
However the SMU version is also used to decide whether to place a timer
based wakeup in the OS_HINT message. If the idlemask hasn't been read
before this message was sent then the SMU version will not have been
cached.
Ensure the SMU version has been read before deciding whether or not to
run this codepath.
Cc: stable@vger.kernel.org # 6.0
Reported-by: You-Sheng Yang <vicamo.yang@canonical.com>
Tested-by: Anson Tsao <anson.tsao@amd.com>
Fixes: b0c07116c8 ("platform/x86: amd-pmc: Avoid reading SMU version at probe time")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20221020113749.6621-2-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
NIC is stopped with rtnl_lock held, and during the stop it cancels the
'service_task' work and free irqs.
However, if CONFIG_MACSEC is set, rtnl_lock is acquired both from
aq_nic_service_task and aq_linkstate_threaded_isr. Then a deadlock
happens if aq_nic_stop tries to cancel/disable them when they've already
started their execution.
As the deadlock is caused by rtnl_lock, it causes many other processes
to stall, not only atlantic related stuff.
Fix it by introducing a mutex that protects each NIC's macsec related
data, and locking it instead of the rtnl_lock from the service task and
the threaded IRQ.
Before this patch, all macsec data was protected with rtnl_lock, but
maybe not all of it needs to be protected. With this new mutex, further
efforts can be made to limit the protected data only to that which
requires it. However, probably it doesn't worth it because all macsec's
data accesses are infrequent, and almost all are done from macsec_ops
or ethtool callbacks, called holding rtnl_lock, so macsec_mutex won't
never be much contended.
The issue appeared repeteadly attaching and deattaching the NIC to a
bond interface. Doing that after this patch I cannot reproduce the bug.
Fixes: 62c1c2e606 ("net: atlantic: MACSec offload skeleton")
Reported-by: Li Liang <liali@redhat.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
Reviewed-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
thinkpad_acpi was reporting 2 fans on a ThinkPad T14s gen 1, even though
the laptop has only 1 fan.
The second, not present fan always reads 65535 (-1 in 16 bit signed),
ignore fans which report 65535 to avoid reporting the non present fan.
Signed-off-by: Jelle van der Waa <jvanderwaa@redhat.com>
Link: https://lore.kernel.org/r/20221019194751.5392-1-jvanderwaa@redhat.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add quirk for ASUS ROG X16 Flow 2-in-1 to enable tablet mode with
lid flip (all screen rotations).
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20221010063009.32293-1-luke@ljones.dev
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The WLAN regulator uses 'gpios' property instead of 'gpio' to specify
regulator enable GPIO. While the former is also currently handled by
the Linux kernel regulator-fixed driver, the later is the correct one
per DT bindings. Update the DT to use the later.
Fixes: 7dd5cbba42 ("ARM: dts: stm32: Enable WiFi on AV96")
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
For cases where DP has HDMI2.1 sink and FRL Link issues are detected,
reset the flag to state FRL trained status before restarting FRL
training.
Fixes: 9488a030ac ("drm/i915: Add support for enabling link status and recovery")
Cc: Swati Sharma <swati2.sharma@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com> (v2)
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221011063447.904649-2-ankit.k.nautiyal@intel.com
(cherry picked from commit 47e1a59e60)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
DGFX platforms has lmem and cpu can access the lmem objects
via mmap and i915 internal i915_gem_object_pin_map() for
i915 own usages. Both of these methods has pre-requisite
requirement to keep GFX PCI endpoint in D0 for a supported
iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1)
Both DG1/DG2 have a known hardware bug that violates the PCIe specs
and support the iomem read write transaction over PCIe bus despite
endpoint is D3 state.
Due to above H/W bug, we had never observed any issue with i915 runtime
PM versus lmem access.
But this issue becomes visible when PCIe gfx endpoint's upstream
bridge enters to D3, at this point any lmem read/write access will be
returned as unsupported request. But again this issue is not observed
on every platform because it has been observed on few host machines
DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver.
which really disables the PCIe power savings and leaves the bridge
at D0 state.
We need a unique interface to read/write from lmem with runtime PM
wakeref protection something similar to intel_uncore_{read, write},
keep autosuspend control to 'on' on all discrete platforms,
until we have a unique interface to read/write from lmem.
This just change the default autosuspend setting of i915 on dGPU,
user can still change it to 'auto'.
v2:
- Modified the commit message and subject with more information.
- Changed the Fixes tag to LMEM support commit. [Joonas]
- Changed !HAS_LMEM() Cond to !IS_DGFX(). [Rodrigo]
Fixes: b908be543e ("drm/i915: support creating LMEM objects")
Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221014113258.1284226-1-anshuman.gupta@intel.com
(cherry picked from commit 66eb93e71a)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Workaround 1607297627 was missed for Alderlake-P, so here extending it
to it and adding the fixes tag so this WA is backported to all
stable kernels.
v2:
- fixed subject
- added Fixes tag
BSpec: 54369
Cc: <stable@vger.kernel.org> # v5.17+
Fixes: dfb924e339 ("drm/i915/adlp: Remove require_force_probe protection")
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221017132432.112850-1-jose.souza@intel.com
(cherry picked from commit 847eec69f0)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Configure ADC support on stm32mp135f-dk. ADC can be used for
USB Type-C CC1 & CC2 pins wired to in6 & in12.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Add a dummy fixed regulator vdd-adc for STM32 ADC,
on STM32MP135F-DK board, while SCMI regulators are not available.
This patch will have to be removed when SCMI regulator support
is added to STM32MP13.
This patch intends to allow ADC enabling on STM32MP13.
With this patch the ADC can probe but it cannot return
valid conversion data, as it's regulator is not actually enabled.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Define pins muxing that can be used for ADC on stm32mp135f-dk board
(USB Type-C CC1 & CC2 pins).
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Add ADC1 and ADC2 support to STM32MP13 SoC family.
The STM32MP131 provides only ADC2, while other STM32MP13 SoCs provide
both ADC1 and ADC2.
Internal channels support limitations:
- VREFINT internal channel requires calibration data from OTP memory.
The nvmem properties used to access OTP are not defined for time being,
as OTP support is not yet enabled.
- VBAT internal channel is not defined by default in SoC DT, and
has be defined in board DT when needed, instead. This avoids unwanted
current consumption on battery, when ADC conversions are performed
on any other channels.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Back in 2014, the LQI was saved in the skb control buffer (skb->cb, or
mac_cb(skb)) without any actual reset of this area prior to its use.
As part of a useful rework of the use of this region, 32edc40ae6
("ieee802154: change _cb handling slightly") introduced mac_cb_init() to
basically memset the cb field to 0. In particular, this new function got
called at the beginning of mac802154_parse_frame_start(), right before
the location where the buffer got actually filled.
What went through unnoticed however, is the fact that the very first
helper called by device drivers in the receive path already used this
area to save the LQI value for later extraction. Resetting the cb field
"so late" led to systematically zeroing the LQI.
If we consider the reset of the cb field needed, we can make it as soon
as we get an skb from a device driver, right before storing the LQI,
as is the very first time we need to write something there.
Cc: stable@vger.kernel.org
Fixes: 32edc40ae6 ("ieee802154: change _cb handling slightly")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20221020142535.1038885-1-miquel.raynal@bootlin.com
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Kuniyuki Iwashima says:
====================
inet6: Remove inet6_destroy_sock() calls.
This is a follow-up series for commit d38afeec26 ("tcp/udp: Call
inet6_destroy_sock() in IPv6 sk->sk_destruct().").
This series cleans up unnecessary inet6_destory_sock() calls in
sk->sk_prot->destroy() and call it from sk->sk_destruct() to make
sure we do not leak memory related to IPv6 specific-resources.
Changes:
v2:
* patch 1
* Fix build failure for CONFIG_MPTCP_IPV6=y
v1: https://lore.kernel.org/netdev/20221018190956.1308-1-kuniyu@amazon.com/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We can reuse the unlock label above and need not repeat the same code.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The last user of inet6_destroy_sock() is its wrapper inet6_cleanup_sock().
Let's rename inet6_destroy_sock() to inet6_cleanup_sock().
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After commit d38afeec26 ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.
SCTP sets its own sk->sk_destruct() in the sctp_init_sock(), and
SCTPv6 socket reuses it as the init function.
To call inet6_sock_destruct() from SCTPv6 sk->sk_destruct(), we
set sctp_v6_destruct_sock() in a new init function.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After commit d38afeec26 ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.
DCCP sets its own sk->sk_destruct() in the dccp_init_sock(), and
DCCPv6 socket shares it by calling the same init function via
dccp_v6_init_sock().
To call inet6_sock_destruct() from DCCPv6 sk->sk_destruct(), we
export it and set dccp_v6_sk_destruct() in the init function.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After commit d38afeec26 ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.
Now we can remove unnecessary inet6_destroy_sock() calls in
sk->sk_prot->destroy().
DCCP and SCTP have their own sk->sk_destruct() function, so we
change them separately in the following patches.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
