| Age | Commit message (Collapse) | Author |
|---|
|
For the dual-role port, it will assign the phy dev to usb-phy dev and
use the port dev driver as the dev driver of usb-phy.
When we try to destroy the port dev, it will destroy its dev driver
as well. But we did not remove the reference from usb-phy dev. This
might cause the use-after-free issue in KASAN.
Fixes: e8f7d2f409a1 ("phy: tegra: xusb: Add usb-phy support")
Cc: stable@vger.kernel.org
Signed-off-by: EJ Hsu <ejh@nvidia.com>
Signed-off-by: Haotien Hsu <haotienh@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20230609062932.3276509-1-haotienh@nvidia.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Always add buses to the stream->master_list in a fixed order.
The unique bus->id is used to order the adding of buses to the
list.
This prevents lockdep asserts and possible deadlocks on streams
that have multiple buses.
sdw_acquire_bus_lock() takes bus_lock in the order that buses
are listed in stream->master_list. do_bank_switch() takes all
the msg_lock in the same order.
To prevent a lockdep assert, and a possible real deadlock, the
relative order of taking these mutexes must always be the same.
For example, if a stream takes the mutexes in the order
(bus0, bus1) lockdep will assert if another stream takes them
in the order (bus1, bus0).
More complex relative ordering will also assert, for example
if two streams take (bus0, bus1) and (bus1, bus2), then a third
stream takes (bus2, bus0).
Previously sdw_stream_add_master() simply added the given bus
to the end of the list, requiring the caller to guarantee that
buses are added in a fixed order. This isn't reasonable or
necessary - it's an internal implementation detail that should
not be exposed by the API. It doesn't really make sense when
there could be multiple independent calling drivers, to say
"you must add your buses in the same order as a different driver,
that you don't know about, added them".
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230615141208.679011-2-rf@opensource.cirrus.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Give the bus_lock and msg_lock of each bus a different unique key
so that it is possible to acquire the locks of multiple buses
without lockdep asserting a possible deadlock.
Using mutex_init() to initialize a mutex gives all those mutexes
the same lock class. Lockdep checking treats it as an error to
attempt to take a mutex while already holding a mutex of the same
class. This causes a lockdep assert when sdw_acquire_bus_lock()
attempts to lock multiple buses, and when do_bank_switch() takes
multiple msg_lock.
[ 138.697350] WARNING: possible recursive locking detected
[ 138.697366] 6.3.0-test #1 Tainted: G E
[ 138.697380] --------------------------------------------
[ 138.697394] play/903 is trying to acquire lock:
[ 138.697409] ffff99b8c41aa8c8 (&bus->bus_lock){+.+.}-{3:3}, at:
sdw_prepare_stream+0x52/0x2e0
[ 138.697443]
but task is already holding lock:
[ 138.697468] ffff99b8c41af8c8 (&bus->bus_lock){+.+.}-{3:3}, at:
sdw_prepare_stream+0x52/0x2e0
[ 138.697493]
other info that might help us debug this:
[ 138.697521] Possible unsafe locking scenario:
[ 138.697540] CPU0
[ 138.697550] ----
[ 138.697559] lock(&bus->bus_lock);
[ 138.697570] lock(&bus->bus_lock);
[ 138.697581]
*** DEADLOCK ***
Giving each mutex a unique key allows multiple to be held
without triggering a lockdep assert. But note that it does not
allow them to be taken in one order then a different order.
If two mutexes are taken in the order A, B then they must
always be taken in that order otherwise they could deadlock.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230615141208.679011-1-rf@opensource.cirrus.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14),
however we index it starting from 1, not 0, to match real port numbers.
This can lead to writing port config past 'pconfig' bounds and
overwriting next member of 'qcom_swrm_ctrl' struct. Reported also by
smatch:
drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14
Fixes: 9916c02ccd74 ("soundwire: qcom: cleanup internal port config indexing")
Cc: <stable@vger.kernel.org>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Link: https://lore.kernel.org/r/202305201301.sCJ8UDKV-lkp@intel.com/
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230601102525.609627-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
We're using pci_irq_vector() to obtain the interrupt number and then
bind it to the CPU start perf under the protection of spinlock in
pmu::start(). pci_irq_vector() might sleep since [1] because it will
call msi_domain_get_virq() to get the MSI interrupt number and it
needs to acquire dev->msi.data->mutex. Getting a mutex will sleep on
contention. So use pci_irq_vector() in an atomic context is problematic.
This patch cached the interrupt number in the probe() and uses the
cached data instead to avoid potential sleep.
[1] commit 82ff8e6b78fc ("PCI/MSI: Use msi_get_virq() in pci_get_vector()")
Fixes: ff0de066b463 ("hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device")
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230621092804.15120-6-yangyicong@huawei.com
|
|
The PTT trace collects PCIe TLP headers from the PCIe link and don't
have the ability to exclude certain context. It doesn't support itrace
as well. So replace PERF_PMU_CAP_ITRACE with PERF_PMU_CAP_NO_EXCLUDE.
This will greatly save the storage of final data. Tested tracing idle
link for ~15s, without this patch we'll collect ~28.682MB data for
additional information and with this patch it reduced to ~0.226MB.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Tested-by: Junhao He <hejunhao3@huawei.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230621092804.15120-5-yangyicong@huawei.com
|
|
The PTT can only filter the traced TLP headers by the Root Ports or the
Requester ID of the Endpoint, which are located on the same PCIe core of
the PTT device. The filter value used is derived from the BDF number of
the supported Root Port or the Endpoint. It's not friendly enough for the
users since it requires the user to be familiar enough with the platform
and calculate the filter value manually.
This patch export the available filters through sysfs. Each available
filters is presented as an individual file with the name of the BDF
number of the related PCIe device. The files are created under
$(PTT PMU dir)/available_root_port_filters and
$(PTT PMU dir)/available_requester_filters respectively. The filter
value can be known by reading the related file.
Then the users can easily know the available filters for trace and get
the filter values without calculating.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230621092804.15120-4-yangyicong@huawei.com
|
|
The PCIe devices supported by the PTT trace can be removed/rescanned by
hotplug or through sysfs. Add support for dynamically updating the
available filter list by registering a PCI bus notifier block. Then user
can always get latest information about available tracing filters and
driver can block the invalid filters of which related devices no longer
exist in the system.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230621092804.15120-3-yangyicong@huawei.com
|
|
Factor out the allocation and release of filters. This will make it easier
to extend and manage the function of the filter.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230621092804.15120-2-yangyicong@huawei.com
|
|
The ace2x driver can be build with or without mlink support, but
when SND_SOC_SOF_HDA_MLINK is set to =m and soundwire is built-in,
it fails with a link error:
ld.lld: error: undefined symbol: hdac_bus_eml_sdw_wait_syncpu_unlocked
>>> referenced by intel_ace2x.c
>>> drivers/soundwire/intel_ace2x.o:(intel_link_power_up) in archive vmlinux.a
ld.lld: error: undefined symbol: hdac_bus_eml_sdw_sync_arm_unlocked
>>> referenced by intel_ace2x.c
>>> drivers/soundwire/intel_ace2x.o:(intel_sync_arm) in archive vmlinux.a
Add a Kconfig dependency that prevents that broken configuration but
still allows soundwire to be a loadable module instead.
Fixes: 4d1e2464a1104 ("soundwire: intel_ace2x: add sync_arm/sync_go helpers")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230616090932.2714714-1-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add the missing MODULE_FIRMWARE macro for "3826.eeprom".
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616121917.1034761-1-juerg.haefliger@canonical.com
|
|
A firmware contains basic header, sections and optional dynamic header.
Define them by a struct, so it will be easier to understand the layout,
and also simply access these elements.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616060601.28460-1-pkshih@realtek.com
|
|
Some old declarations about TX power stuffs were named with confusing
`_max`. But, they mean "the number of". So we change them to be named
with `_num`.
(No logic is changed.)
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616060523.28396-1-pkshih@realtek.com
|
|
RTL8851B is a chip with only single RF path, and it must use 1 TX power
value for transmission, so force 1 TX power value to prevent hardware
logic gets wrong TX power values randomly in certain samples.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230615130442.18116-6-pkshih@realtek.com
|
|
The main change is to adjust RX calibration groups from {0,1,2,3} to {0,2}
in 5 GHz, so reduce elements from 4 to 2, and use index to iterate them.
Meanwhile, always do RX narrowband calibration (ID_NBRXK) for each group.
NCTL is used to assist IQK, so also update NCTL to 0x6 along with internal
tag HALRF_029_00_103.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230615130442.18116-5-pkshih@realtek.com
|
|
LCK is short for LC Tank calibration. To keep RF performance, do this
calibration if difference of thermal value is over a threshold.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230615130442.18116-4-pkshih@realtek.com
|
|
Update 8851B TX power tables to RF version R28.
TX power tables' changes:
* TX power limit and TX power shape:
update 5 GHz configurations for FCC and IC
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230615130442.18116-3-pkshih@realtek.com
|
|
Update 8851b radio A parameters to R28 along with internal HALRF_029_00_103
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230615130442.18116-2-pkshih@realtek.com
|
|
Without this patch, firmware only track beacons for port 0 and since
we will always start AP on port 0, this results in misbehavior of
power saving mode on other ports after AP stops.
The "default port" H2C command is used to notify which port should
firmware track. Update the correct settings to firmware so power
saving mode can work properly.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616125540.36877-7-pkshih@realtek.com
|
|
Since register based H2C commands don't need endian conversion.
Introduce a new API that don't do conversion and send it directly.
New caller are expected to encode with cpu order and gradually
replace the old ones.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616125540.36877-6-pkshih@realtek.com
|
|
When traversing channel list, TX in high queue should be disabled
along with beacon function, so packets won't be sent to incorrect
channels.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616125540.36877-5-pkshih@realtek.com
|
|
The flush period may not always intersect with DTIM and when that
happens, an error log "timed out to flush pci TX ring[6]" is shown.
Bypass this since hardware will do proper transmission on the next
DTIM period for broadcast/multicast packets in high queue.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616125540.36877-4-pkshih@realtek.com
|
|
Broadcast and multicast packets in high queue should be transmitted
all at once during DTIM. But without proper settings, hardware fails
to recognize that there are multiple packets and fetches only one.
Fix this by signaling hardware with more data bit set when there are
packets in the high queue.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616125540.36877-3-pkshih@realtek.com
|
|
Remove macros that set TX descriptors. Use struct and
le32_encode_bits() with mask definitions.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616125540.36877-2-pkshih@realtek.com
|
|
In the wpa_supplicant rekey flow, it sends an EAPOL packet 4/4 through
nl80211_tx_control_port() and triggers wake_tx_queue() in the driver.
Then, it sends nl80211_new_key() to configure a new key in mac80211.
However, in wake_tx_queue(), a workqueue is used to process the tx packet,
which might cause the driver to process the EAPOL packet later than
nl80211_new_key(). As a result, the EAPOL 4/4 packet is dropped by mac80211
due to the rekey configuration being finished. The EAPOL packets belongs to
VO packets that need high priority. Therefore, we process VO packets
directly without workqueue to ensure that packets can process immediately.
VO is normally used by voice application that is low traffic load and low
latency, that doesn't affect user experience.
We test iperf with VO packets(iperf3 -P4 -u -b 10000M -S 0xdf)
before after
TX throughput 162M 162M
ping RTT 3.8ms 3.7ms
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230616031713.16769-1-pkshih@realtek.com
|
|
For combo chips, antennas were controlled by bluetooth only during
power on. If WiFi wish to do transmission, notification to the coexistence
module are required. Previously we only do this before authentication.
To allow transmission before auth, such as management TX, now we start
the initiation of coexistence earlier so antennas are shared between
WiFi and bluetooth after set_channel(), and frames could then be sent.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230615114348.7193-1-pkshih@realtek.com
|
|
This reverts commit 07b679f70d73483930e8d3c293942416d9cd5c13.
This change appears to have broken things...
We now see applications hanging during disk accesses.
e.g.
multi-port virtio-blk device running in h/w (FPGA)
Host running a simple 'fio' test.
[global]
thread=1
direct=1
ioengine=libaio
norandommap=1
group_reporting=1
bs=4K
rw=read
iodepth=128
runtime=1
numjobs=4
time_based
[job0]
filename=/dev/vda
[job1]
filename=/dev/vdb
[job2]
filename=/dev/vdc
...
[job15]
filename=/dev/vdp
i.e. 16 disks; 4 queues per disk; simple burst of 4KB reads
This is repeatedly run in a loop.
After a few, normally <10 seconds, fio hangs.
With 64 queues (16 disks), failure occurs within a few seconds; with 8 queues (2 disks) it may take ~hour before hanging.
Last message:
fio-3.19
Starting 8 threads
Jobs: 1 (f=1): [_(7),R(1)][68.3%][eta 03h:11m:06s]
I think this means at the end of the run 1 queue was left incomplete.
'diskstats' (run while fio is hung) shows no outstanding transactions.
e.g.
$ cat /proc/diskstats
...
252 0 vda 1843140071 0 14745120568 712568645 0 0 0 0 0 3117947 712568645 0 0 0 0 0 0
252 16 vdb 1816291511 0 14530332088 704905623 0 0 0 0 0 3117711 704905623 0 0 0 0 0 0
...
Other stats (in the h/w, and added to the virtio-blk driver ([a]virtio_queue_rq(), [b]virtblk_handle_req(), [c]virtblk_request_done()) all agree, and show every request had a completion, and that virtblk_request_done() never gets called.
e.g.
PF= 0 vq=0 1 2 3
[a]request_count - 839416590 813148916 105586179 84988123
[b]completion1_count - 839416590 813148916 105586179 84988123
[c]completion2_count - 0 0 0 0
PF= 1 vq=0 1 2 3
[a]request_count - 823335887 812516140 104582672 75856549
[b]completion1_count - 823335887 812516140 104582672 75856549
[c]completion2_count - 0 0 0 0
i.e. the issue is after the virtio-blk driver.
This change was introduced in kernel 6.3.0.
I am seeing this using 6.3.3.
If I run with an earlier kernel (5.15), it does not occur.
If I make a simple patch to the 6.3.3 virtio-blk driver, to skip the blk_mq_add_to_batch()call, it does not fail.
e.g.
kernel 5.15 - this is OK
virtio_blk.c,virtblk_done() [irq handler]
if (likely(!blk_should_fake_timeout(req->q))) {
blk_mq_complete_request(req);
}
kernel 6.3.3 - this fails
virtio_blk.c,virtblk_handle_req() [irq handler]
if (likely(!blk_should_fake_timeout(req->q))) {
if (!blk_mq_complete_request_remote(req)) {
if (!blk_mq_add_to_batch(req, iob, virtblk_vbr_status(vbr), virtblk_complete_batch)) {
virtblk_request_done(req); //this never gets called... so blk_mq_add_to_batch() must always succeed
}
}
}
If I do, kernel 6.3.3 - this is OK
virtio_blk.c,virtblk_handle_req() [irq handler]
if (likely(!blk_should_fake_timeout(req->q))) {
if (!blk_mq_complete_request_remote(req)) {
virtblk_request_done(req); //force this here...
if (!blk_mq_add_to_batch(req, iob, virtblk_vbr_status(vbr), virtblk_complete_batch)) {
virtblk_request_done(req); //this never gets called... so blk_mq_add_to_batch() must always succeed
}
}
}
Perhaps you might like to fix/test/revert this change...
Martin
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202306090826.C1fZmdMe-lkp@intel.com/
Cc: Suwan Kim <suwan.kim027@gmail.com>
Tested-by: edliaw@google.com
Reported-by: "Roberts, Martin" <martin.roberts@intel.com>
Message-Id: <336455b4f630f329380a8f53ee8cad3868764d5c.1686295549.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
|
|
s/ep_chg_chg_id/ep_chg_id in documentation of master clock structure.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-12-claudiu.beznea@microchip.com
|
|
Switch SAMA7G5 clocks to use parent_hw and parent_data. Having
parent_hw instead of parent names improves to clock registration
speed and re-parenting. Extra time saved on registration is
~250us when running at 800MHz.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-11-claudiu.beznea@microchip.com
|
|
Switch slow clock drivers to use parent_data and parent_hw.
With this parent-child relation is described with pointers rather
than strings.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-10-claudiu.beznea@microchip.com
|
|
Add support for parent_hw in SAM9X60 PLL clock drivers.
With this parent-child relation is described with pointers rather
than strings making registration a bit faster.
All the SoC based drivers that rely on clk-sam9x60-pll were adapted
to the new API change. The switch itself for SoCs will be done
in subsequent patches.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-9-claudiu.beznea@microchip.com
|
|
Add support for parent_hw in utmi clock drivers.
With this parent-child relation is described with pointers rather
than strings making registration a bit faster.
All the SoC based drivers that rely on clk-utmi were adapted
to the new API change. The switch itself for SoCs will be done
in subsequent patches.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-8-claudiu.beznea@microchip.com
|
|
Add support for parent_hw in system clock drivers.
With this parent-child relation is described with pointers rather
than strings making registration a bit faster.
All the SoC based drivers that rely on clk-system were adapted
to the new API change. The switch itself for SoCs will be done
in subsequent patches.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-7-claudiu.beznea@microchip.com
|
|
Add support for parent_hw in programmable clock driver.
With this parent-child relation is described with pointers rather
than strings making registration a bit faster.
All the SoC based drivers that rely on clk-programmable were adapted
to the new API change. The switch itself for SoCs will be done
in subsequent patches.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-6-claudiu.beznea@microchip.com
|
|
Add support for parent_hw in peripheral clock drivers.
With this parent-child relation is described with pointers rather
than strings making registration a bit faster.
All the SoC based drivers that rely on clk-peripheral were adapted
to the new API change. The switch itself for SoCs will be done
in subsequent patches.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-5-claudiu.beznea@microchip.com
|
|
Add support for parent_hw in master clock drivers.
With this parent-child relation is described with pointers rather
than strings making registration a bit faster.
All the SoC based drivers that rely on clk-master were adapted
to the new API change. The switch itself for SoCs will be done
in subsequent patches.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-4-claudiu.beznea@microchip.com
|
|
Add support for parent_hw in generic clock drivers.
With this parent-child relation is described with pointers rather
than strings making registration a bit faster.
All the SoC based drivers that rely on clk-generated were adapted
to the new API change. The switch itself for SoCs will be done
in subsequent patches.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-3-claudiu.beznea@microchip.com
|
|
Add support for parent_data and parent_hw in main oscillator clock drivers.
With this parent-child relations are described with pointers rather
than strings making registration a bit faster.
All the SoC based drivers that rely on clk-main were adapted
to the new API change. The switch itself for SoCs will be done
in subsequent patches.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20230615093227.576102-2-claudiu.beznea@microchip.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel
intel-pinctrl for v6.5-1
* Fix of OPEN DRAIN pin mode setting in a few drivers
* Reduce a scope of spin lock in the Bay Trail driver
* Decrease a code footprint by refactoring in a few drivers
* Expand string choices and reuse that in the Bay Trail driver
The following is an automated git shortlog grouped by driver:
baytrail:
- invert if condition
- add warning for BYT_VAL_REG retrieval failure
- reduce scope of spinlock in ->dbg_show() hook
- Use str_hi_lo() helper
- Use BIT() in BYT_PULL_ASSIGN_* definitions
- Unify style of error and debug messages
cherryview:
- Drop goto label
- Return correct value if pin in push-pull mode
- Don't use IRQ core constanst for invalid IRQ
intel:
- refine ->irq_set_type() hook
- refine ->set_mux() hook
- Add Intel Meteor Lake-S pin controller support
lib/string_helpers:
- Add str_high_low() helper
- Split out string_choices.h
- Add missing header files to MAINTAINERS database
merrifield:
- Use BUFCFG_PINMODE_GPIO in ->pin_dbg_show()
- Fix open-drain pin mode configuration
moorefield:
- Use BUFCFG_PINMODE_GPIO in ->pin_dbg_show()
- Fix open-drain pin mode configuration
|
|
Use the recently added of_property_read_reg() helper to get the
untranslated "reg" address value.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230609182926.1763589-1-robh@kernel.org
|
|
Replace open coded reading of "reg" and of_translate_address() calls with
single call to of_address_to_resource().
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230319163226.226583-1-robh@kernel.org
|
|
sa8775p uses EMAC version 4, add the relevant defines, rename the
has_emac3 switch to has_emac_ge_3 (has emac greater-or-equal than 3)
and add the new compatible.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
On some platforms, the PCS can be integrated in the MAC so the driver
will not see any PCS link activity. Add a switch that allows the platform
drivers to let the core code know.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
On sa8775p the MAC is connected to the external PHY over SGMII so add
support for it to the driver.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In preparation for supporting SGMII, let's make the code a bit more
generic. Add a new callback for MAC configuration so that we can assign
a different variant of it in the future.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
On sa8775p, the EMAC revision is 4 and we use SGMII instead of RGMII.
There's no "rgmii" clock but there's a fourth clock under a different
name: "phyaux". Add a new field to the chip data struct that specifies
the link clock name. Default to "rgmii" for backward compatibility.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
On sa8775p platforms, there's a SGMII SerDes PHY between the MAC and
external PHY that we need to enable and configure.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
There's an unnecessary space in the rgmii_updatel() function, remove it.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Typically we use a newline between global and local headers so add it
here as well.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
device_get_phy_mode() is declared in linux/property.h but this header
is not included.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
