* Re: [PATCH v3 06/10] ASoC: tegra: add Tegra186 based DSPK driver
From: Jon Hunter @ 2020-02-20 15:10 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-7-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital Speaker Controller (DSPK) converts the multi-bit Pulse Code
> Modulation (PCM) audio input to oversampled 1-bit Pulse Density Modulation
> (PDM) output. From the signal flow perpsective, the DSPK can be viewed as
> a PDM transmitter that up-samples the input to the desired sampling rate
> by interpolation then converts the oversampled PCM input to the desired
> 1-bit output via Delta Sigma Modulation (DSM).
>
> This patch registers DSPK component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DSPK interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DSPK devices can be enabled in the DT via
> "nvidia,tegra186-dspk" compatible binding. This driver can be used
> on Tegra194 chip as well.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> sound/soc/tegra/Kconfig | 13 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra186_dspk.c | 510 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra186_dspk.h | 73 ++++++
> 4 files changed, 598 insertions(+)
> create mode 100644 sound/soc/tegra/tegra186_dspk.c
> create mode 100644 sound/soc/tegra/tegra186_dspk.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 06/10] ASoC: tegra: add Tegra186 based DSPK driver
From: Jon Hunter @ 2020-02-20 15:10 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-7-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital Speaker Controller (DSPK) converts the multi-bit Pulse Code
> Modulation (PCM) audio input to oversampled 1-bit Pulse Density Modulation
> (PDM) output. From the signal flow perpsective, the DSPK can be viewed as
> a PDM transmitter that up-samples the input to the desired sampling rate
> by interpolation then converts the oversampled PCM input to the desired
> 1-bit output via Delta Sigma Modulation (DSM).
>
> This patch registers DSPK component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DSPK interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DSPK devices can be enabled in the DT via
> "nvidia,tegra186-dspk" compatible binding. This driver can be used
> on Tegra194 chip as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 13 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra186_dspk.c | 510 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra186_dspk.h | 73 ++++++
> 4 files changed, 598 insertions(+)
> create mode 100644 sound/soc/tegra/tegra186_dspk.c
> create mode 100644 sound/soc/tegra/tegra186_dspk.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for tools/i915-perf: workaround overzelous compiler warnings (rev2)
From: Patchwork @ 2020-02-20 15:10 UTC (permalink / raw)
To: Lionel Landwerlin; +Cc: igt-dev
In-Reply-To: <20200220133416.1194071-1-lionel.g.landwerlin@intel.com>
== Series Details ==
Series: tools/i915-perf: workaround overzelous compiler warnings (rev2)
URL : https://patchwork.freedesktop.org/series/73709/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4196
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and IGTPW_4196:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 1 dmesg-warn(s) 17 pass(s) 23 skip(s)
- Exec time: [0.0, 0.24] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 1 dmesg-warn(s) 29 pass(s) 11 skip(s)
- Exec time: [0.0, 6.85] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 1 dmesg-warn(s) 29 pass(s) 11 skip(s)
- Exec time: [0.44, 11.31] s
* igt@i915_pm_rps@basic-api:
- Statuses : 36 pass(s) 5 skip(s)
- Exec time: [0.0, 0.01] s
Known issues
------------
Here are the changes found in IGTPW_4196 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
- fi-byt-n2820: [PASS][3] -> [INCOMPLETE][4] ([i915#45])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_close_race@basic-threads.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-byt-n2820/igt@gem_close_race@basic-threads.html
* igt@gem_flink_basic@bad-flink:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([CI#94] / [i915#402])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_flink_basic@bad-flink.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_flink_basic@bad-flink.html
* igt@i915_selftest@live_gtt:
- fi-bdw-5557u: [PASS][7] -> [TIMEOUT][8] ([fdo#112271])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [FAIL][9] ([CI#94]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html
* igt@gem_mmap@basic:
- fi-tgl-y: [DMESG-WARN][11] ([CI#94] / [i915#402]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_mmap@basic.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_mmap@basic.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][13] ([i915#877]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][15] ([i915#217]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 47)
------------------------------
Additional (5): fi-kbl-soraka fi-ivb-3770 fi-pnv-d510 fi-skl-lmem fi-kbl-7560u
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4196
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4196: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* [dpdk-dev] [PATCH] cryptodev: fix missing device id range checking
From: Adam Dybkowski @ 2020-02-20 15:04 UTC (permalink / raw)
To: dev, fiona.trahe, akhil.goyal; +Cc: Adam Dybkowski, stable
This patch adds range-checking of the device id passed from
the user app code. It prevents out-of-range array accesses
which in some situations resulted in an
application crash (segfault).
Fixes: 3dd4435cf473 ("cryptodev: fix checks related to device id")
Cc: stable@dpdk.org
Signed-off-by: Adam Dybkowski <adamx.dybkowski@intel.com>
---
lib/librte_cryptodev/rte_cryptodev.c | 41 +++++++++++++++++++++++++---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 6d1d0e9d3..65d61a3ef 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -529,7 +529,8 @@ rte_cryptodev_pmd_get_named_dev(const char *name)
static inline uint8_t
rte_cryptodev_is_valid_device_data(uint8_t dev_id)
{
- if (rte_crypto_devices[dev_id].data == NULL)
+ if (dev_id >= RTE_CRYPTO_MAX_DEVS ||
+ rte_crypto_devices[dev_id].data == NULL)
return 0;
return 1;
@@ -621,8 +622,9 @@ rte_cryptodev_devices_get(const char *driver_name, uint8_t *devices,
void *
rte_cryptodev_get_sec_ctx(uint8_t dev_id)
{
- if (rte_crypto_devices[dev_id].feature_flags &
- RTE_CRYPTODEV_FF_SECURITY)
+ if (dev_id < RTE_CRYPTO_MAX_DEVS &&
+ (rte_crypto_devices[dev_id].feature_flags &
+ RTE_CRYPTODEV_FF_SECURITY))
return rte_crypto_devices[dev_id].security_ctx;
return NULL;
@@ -793,6 +795,11 @@ rte_cryptodev_queue_pair_count(uint8_t dev_id)
{
struct rte_cryptodev *dev;
+ if (!rte_cryptodev_is_valid_device_data(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return 0;
+ }
+
dev = &rte_crypto_devices[dev_id];
return dev->data->nb_queue_pairs;
}
@@ -1258,6 +1265,11 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
uint8_t index;
int ret;
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return -EINVAL;
+ }
+
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (sess == NULL || xforms == NULL || dev == NULL)
@@ -1297,6 +1309,11 @@ rte_cryptodev_asym_session_init(uint8_t dev_id,
uint8_t index;
int ret;
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return -EINVAL;
+ }
+
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (sess == NULL || xforms == NULL || dev == NULL)
@@ -1432,6 +1449,11 @@ rte_cryptodev_sym_session_clear(uint8_t dev_id,
struct rte_cryptodev *dev;
uint8_t driver_id;
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return -EINVAL;
+ }
+
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (dev == NULL || sess == NULL)
@@ -1456,6 +1478,11 @@ rte_cryptodev_asym_session_clear(uint8_t dev_id,
{
struct rte_cryptodev *dev;
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return -EINVAL;
+ }
+
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (dev == NULL || sess == NULL)
@@ -1789,8 +1816,14 @@ rte_cryptodev_driver_id_get(const char *name)
const char *
rte_cryptodev_name_get(uint8_t dev_id)
{
- struct rte_cryptodev *dev = rte_cryptodev_pmd_get_dev(dev_id);
+ struct rte_cryptodev *dev;
+ if (!rte_cryptodev_is_valid_device_data(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%" PRIu8, dev_id);
+ return NULL;
+ }
+
+ dev = rte_cryptodev_pmd_get_dev(dev_id);
if (dev == NULL)
return NULL;
--
2.17.1
^ permalink raw reply related
* [Cluster-devel] [PATCH v7 10/24] mm: Add readahead address space operation
From: Matthew Wilcox @ 2020-02-20 15:10 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <5D7CE6BD-FABD-4901-AEF0-E0F10FC00EB1@nvidia.com>
On Thu, Feb 20, 2020 at 10:00:30AM -0500, Zi Yan wrote:
> > +/* The index of the first page in this readahead block */
> > +static inline unsigned int readahead_index(struct readahead_control *rac)
> > +{
> > + return rac->_index;
> > +}
>
> rac->_index is pgoff_t, so readahead_index() should return the same type, right?
> BTW, pgoff_t is unsigned long.
Oh my goodness! Thank you for spotting that. Fortunately, it's only
currently used by tracepoints, so it wasn't causing any trouble, but
that's a nasty landmine to leave lying around. Fixed:
static inline pgoff_t readahead_index(struct readahead_control *rac)
^ permalink raw reply
* [Ocfs2-devel] [PATCH v7 10/24] mm: Add readahead address space operation
From: Matthew Wilcox @ 2020-02-20 15:10 UTC (permalink / raw)
To: Zi Yan
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <5D7CE6BD-FABD-4901-AEF0-E0F10FC00EB1@nvidia.com>
On Thu, Feb 20, 2020 at 10:00:30AM -0500, Zi Yan wrote:
> > +/* The index of the first page in this readahead block */
> > +static inline unsigned int readahead_index(struct readahead_control *rac)
> > +{
> > + return rac->_index;
> > +}
>
> rac->_index is pgoff_t, so readahead_index() should return the same type, right?
> BTW, pgoff_t is unsigned long.
Oh my goodness! Thank you for spotting that. Fortunately, it's only
currently used by tracepoints, so it wasn't causing any trouble, but
that's a nasty landmine to leave lying around. Fixed:
static inline pgoff_t readahead_index(struct readahead_control *rac)
^ permalink raw reply
* Re: [PATCH v7 10/24] mm: Add readahead address space operation
From: Matthew Wilcox @ 2020-02-20 15:10 UTC (permalink / raw)
To: Zi Yan
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <5D7CE6BD-FABD-4901-AEF0-E0F10FC00EB1@nvidia.com>
On Thu, Feb 20, 2020 at 10:00:30AM -0500, Zi Yan wrote:
> > +/* The index of the first page in this readahead block */
> > +static inline unsigned int readahead_index(struct readahead_control *rac)
> > +{
> > + return rac->_index;
> > +}
>
> rac->_index is pgoff_t, so readahead_index() should return the same type, right?
> BTW, pgoff_t is unsigned long.
Oh my goodness! Thank you for spotting that. Fortunately, it's only
currently used by tracepoints, so it wasn't causing any trouble, but
that's a nasty landmine to leave lying around. Fixed:
static inline pgoff_t readahead_index(struct readahead_control *rac)
^ permalink raw reply
* Re: [PATCH v7 10/24] mm: Add readahead address space operation
From: Matthew Wilcox @ 2020-02-20 15:10 UTC (permalink / raw)
To: Zi Yan
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-fsdevel, linux-ext4, linux-erofs,
linux-btrfs
In-Reply-To: <5D7CE6BD-FABD-4901-AEF0-E0F10FC00EB1@nvidia.com>
On Thu, Feb 20, 2020 at 10:00:30AM -0500, Zi Yan wrote:
> > +/* The index of the first page in this readahead block */
> > +static inline unsigned int readahead_index(struct readahead_control *rac)
> > +{
> > + return rac->_index;
> > +}
>
> rac->_index is pgoff_t, so readahead_index() should return the same type, right?
> BTW, pgoff_t is unsigned long.
Oh my goodness! Thank you for spotting that. Fortunately, it's only
currently used by tracepoints, so it wasn't causing any trouble, but
that's a nasty landmine to leave lying around. Fixed:
static inline pgoff_t readahead_index(struct readahead_control *rac)
^ permalink raw reply
* Re: [PATCH] ext4: fix handling mount -o remount,nolazytime
From: Konstantin Khlebnikov @ 2020-02-20 15:11 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Andreas Dilger, linux-ext4, Karel Zak, Dmitry Monakhov
In-Reply-To: <20200219162242.GI330201@mit.edu>
On 19/02/2020 19.22, Theodore Y. Ts'o wrote:
> On Wed, Feb 19, 2020 at 12:19:52PM +0300, Konstantin Khlebnikov wrote:
>> Tool "mount" from util-linux >= 2.27 knows about flag MS_LAZYTIME and
>> handles options "lazytime" and "nolazytime" as fs-independent.
>>
>> For ext4 it works for enabling lazytime: mount(MS_REMOUNT | MS_LAZYTIME),
>> but does not work for disabling: mount(MS_REMOUNT).
>>
>> Currently ext4 has performance issue in lazytime implementation caused by
>> contention around inode_hash_lock in ext4_update_other_inodes_time().
>>
>> Fortunately lazytime still could be disabled without unmounting by passing
>> "nolazytime" as fs-specific mount option: mount(MS_REMOUNT, "nolazytime").
>> But modern versions of tool "mount" cannot do that.
>>
>> This patch fixes remount for modern tool and keeps backward compatibility.
>
> Actually, if you are using ancient versions of mount that don't know
> about MS_LAZYTIME, then when you do something like mount -o
> remount,usrquota /dev/sdb" with your patch, it will disable
> MS_LAZYTIME, which would be a backwards incompatible change.
>
> So if we make this change, and there is someone who wants to use
> lazytime on some ancient enterprise linux system which is still using
> an old version of util-linux, and then take a kernel with this change,
> then it will result in a change in the behavior they will see. The
> good news is that RHEL 8 is using util-linux 2.32, but RHEL 7 is still
> using util-linux 2.23.
>
> Lazytime is not enabled by default, so this issue is really only a
> problem for someone which explicitly enables lazytime using a newer
> version of util-linux, and then disables lazytime with a newer version
> of util-linux. So the behaviour of a2fd66d069d8 ("ext4: set lazytime
> on remount if MS_LAZYTIME is set by mount") was in fact an explicit
> decision to do things in that way.
>
> So maybe we might want to change things, assuming that it's unlikely
> users will try to be running new kernels on ancient distros. But I
> really wouldn't want to add a Fixes tag, and I would want to make sure
> this doesn't get backported to older kernels, since the change does
> *not* keep backwards compatibility.
>
> Unfortunately, it's not possible to do this without breaking
> compatibility for at least some systems. The question is whether or
> not we think systems running util-linux less than 2.27 is something we
> care about for new kernels. Times may have changed since
> a2fd66d069d8.
>
> So I might be willing to take this patch (I invite comments from
> others), but there will need to be a DO NOT BACKPORT warning in the
> commit description.
Usually all these options are saved in /etc/fstab and
mount -o remount,... includes them into line passed into syscall.
In this case remounting any other option will not disable lazytime.
But there might be implementations of /bin/mount which doesn't do that.
>
> Cheers,
>
> - Ted
>
^ permalink raw reply
* Re: [PATCH 1/4] Btrfs: move all reflink implementation code into its own file
From: Josef Bacik @ 2020-02-20 15:11 UTC (permalink / raw)
To: fdmanana, linux-btrfs
In-Reply-To: <20200219140547.1641512-1-fdmanana@kernel.org>
On 2/19/20 9:05 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> The reflink code is quite large and has been living in ioctl.c since ever.
> It has grown over the years after many bug fixes and improvements, and
> since I'm planning on making some further improvements on it, it's time
> to get it better organized by moving into its own file, reflink.c
> (similar to what xfs does for example).
>
> This change only moves the code out of ioctl.c into the new file, it
> doesn't do any other change.
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* [PATCH v6 05/16] arc/mm: Use helper fault_signal_pending()
From: Peter Xu @ 2020-02-20 15:11 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Peter Xu, Martin Cracauer, Mike Rapoport, Hugh Dickins,
Jerome Glisse, Kirill A . Shutemov, Matthew Wilcox,
Pavel Emelyanov, Brian Geffon, Maya Gokhale, Denis Plotnikov,
Andrea Arcangeli, Johannes Weiner, Dr . David Alan Gilbert,
Linus Torvalds, Mike Kravetz, Marty McFadden, David Hildenbrand,
Bobby Powers, Mel Gorman
In-Reply-To: <20200220145432.4561-1-peterx@redhat.com>
Let ARC to use the new helper fault_signal_pending() by moving the
signal check out of the retry logic as standalone. This should also
helps to simplify the code a bit.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
arch/arc/mm/fault.c | 34 +++++++++++++---------------------
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index fb86bc3e9b35..6eb821a59b49 100644
--- a/arch/arc/mm/fault.c
+++ b/arch/arc/mm/fault.c
@@ -133,29 +133,21 @@ void do_page_fault(unsigned long address, struct pt_regs *regs)
fault = handle_mm_fault(vma, address, flags);
+ /* Quick path to respond to signals */
+ if (fault_signal_pending(fault, regs)) {
+ if (!user_mode(regs))
+ goto no_context;
+ return;
+ }
+
/*
- * Fault retry nuances
+ * Fault retry nuances, mmap_sem already relinquished by core mm
*/
- if (unlikely(fault & VM_FAULT_RETRY)) {
-
- /*
- * If fault needs to be retried, handle any pending signals
- * first (by returning to user mode).
- * mmap_sem already relinquished by core mm for RETRY case
- */
- if (fatal_signal_pending(current)) {
- if (!user_mode(regs))
- goto no_context;
- return;
- }
- /*
- * retry state machine
- */
- if (flags & FAULT_FLAG_ALLOW_RETRY) {
- flags &= ~FAULT_FLAG_ALLOW_RETRY;
- flags |= FAULT_FLAG_TRIED;
- goto retry;
- }
+ if (unlikely((fault & VM_FAULT_RETRY) &&
+ (flags & FAULT_FLAG_ALLOW_RETRY))) {
+ flags &= ~FAULT_FLAG_ALLOW_RETRY;
+ flags |= FAULT_FLAG_TRIED;
+ goto retry;
}
bad_area:
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v3 06/10] ASoC: tegra: add Tegra186 based DSPK driver
From: Jon Hunter @ 2020-02-20 15:10 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-7-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital Speaker Controller (DSPK) converts the multi-bit Pulse Code
> Modulation (PCM) audio input to oversampled 1-bit Pulse Density Modulation
> (PDM) output. From the signal flow perpsective, the DSPK can be viewed as
> a PDM transmitter that up-samples the input to the desired sampling rate
> by interpolation then converts the oversampled PCM input to the desired
> 1-bit output via Delta Sigma Modulation (DSM).
>
> This patch registers DSPK component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DSPK interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DSPK devices can be enabled in the DT via
> "nvidia,tegra186-dspk" compatible binding. This driver can be used
> on Tegra194 chip as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 13 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra186_dspk.c | 510 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra186_dspk.h | 73 ++++++
> 4 files changed, 598 insertions(+)
> create mode 100644 sound/soc/tegra/tegra186_dspk.c
> create mode 100644 sound/soc/tegra/tegra186_dspk.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Jan Beulich @ 2020-02-20 15:11 UTC (permalink / raw)
To: Roger Pau Monné
Cc: Jürgen Groß, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
xen-devel
In-Reply-To: <20200220143841.GL4679@Air-de-Roger>
On 20.02.2020 15:38, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 03:23:38PM +0100, Jürgen Groß wrote:
>> On 20.02.20 15:11, Roger Pau Monné wrote:
>>> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
>>>> On 20.02.2020 13:02, Roger Pau Monne wrote:
>>>>> @@ -166,7 +180,8 @@ static inline void _write_unlock(rwlock_t *lock)
>>>>> * If the writer field is atomic, it can be cleared directly.
>>>>> * Otherwise, an atomic subtraction will be used to clear it.
>>>>> */
>>>>> - atomic_sub(_QW_LOCKED, &lock->cnts);
>>>>> + ASSERT(_is_write_locked_by_me(atomic_read(&lock->cnts)));
>>>>> + atomic_sub(_write_lock_val(), &lock->cnts);
>>>>
>>>> I think this would be more efficient with atomic_and(), not
>>>> the least because of the then avoided smp_processor_id().
>>>> Whether to mask off just _QW_WMASK or also the CPU number of
>>>> the last write owner would need to be determined. But with
>>>> using subtraction, in case of problems it'll likely be
>>>> harder to understand what actually went on, from looking at
>>>> the resulting state of the lock (this is in part a pre-
>>>> existing problem, but gets worse with subtraction of CPU
>>>> numbers).
>>>
>>> Right, a mask would be better. Right now both need to be cleared (the
>>> LOCKED and the CPU fields) as there's code that relies on !lock->cnts
>>> as a way to determine that the lock is not read or write locked. If we
>>> left the CPU lying around those checks would need to be adjusted.
>>
>> In case you make _QR_SHIFT 16 it is possible to just write a 2-byte zero
>> value for write_unlock() (like its possible to do so today using a
>> single byte write).
>
> That would limit the readers count to 65536, what do you think Jan?
If the recurse_cpu approach is considered bad, I think this would
be acceptable. But of course you'll need to consult with the Arm
guys regarding the correctness of such a "half" store in their
memory model; I would hope this to be universally okay, but I'm
not entirely certain.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH v2 0/3] Migration mechanism with FD
From: Oksana Vohchana @ 2020-02-20 15:10 UTC (permalink / raw)
To: qemu-devel; +Cc: ovoshcha, philmd, ehabkost, wainersm, crosa
To test migration through the file descriptor we should build and provide
a path to socket_scm_helper file. This way is inconvenient for acceptance
testing.
This series provides new functions to receive and send messages over a UNIX
socket. And adds a new migration test.
v2:
- Fix warning of line over 80 characters
Oksana Vohchana (3):
Adding functions _send_fds and _recv_fds
Updates send_fd_scm function
Acceptance test: FD migration
python/qemu/machine.py | 88 +++++++++++++++++++++++++----------
tests/acceptance/migration.py | 21 +++++++++
2 files changed, 85 insertions(+), 24 deletions(-)
--
2.21.1
^ permalink raw reply
* [PATCH v2 3/3] Acceptance test: FD migration
From: Oksana Vohchana @ 2020-02-20 15:10 UTC (permalink / raw)
To: qemu-devel; +Cc: ovoshcha, philmd, ehabkost, wainersm, crosa
In-Reply-To: <20200220151039.20552-1-ovoshcha@redhat.com>
Adds a new migration test through the file descriptor.
Signed-off-by: Oksana Vohchana <ovoshcha@redhat.com>
---
tests/acceptance/migration.py | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/tests/acceptance/migration.py b/tests/acceptance/migration.py
index a8367ca023..7f4879ce5d 100644
--- a/tests/acceptance/migration.py
+++ b/tests/acceptance/migration.py
@@ -10,7 +10,10 @@
# later. See the COPYING file in the top-level directory.
+import os
import tempfile
+from socket import socketpair, AF_UNIX, SOCK_STREAM
+
from avocado_qemu import Test
from avocado import skipUnless
@@ -75,3 +78,21 @@ class Migration(Test):
"""
free_port = self._get_free_port()
dest_uri = 'exec:nc -l localhost %u' % free_port
+
+ def test_migration_with_fd(self):
+ opaque = 'fd-migration'
+ data_to_send = b"{\"execute\": \"getfd\", \"arguments\": \
+ {\"fdname\": \"fd-migration\"}}"
+ send_socket, recv_socket = socketpair(AF_UNIX, SOCK_STREAM)
+ fd1 = send_socket.fileno()
+ fd2 = recv_socket.fileno()
+ os.set_inheritable(fd2, True)
+
+ source_vm = self.get_vm()
+ source_vm.launch()
+ source_vm.send_fd_scm(fd=fd1, data=data_to_send)
+
+ dest_vm = self.get_vm('-incoming', 'fd:%s' % fd2)
+ dest_vm.launch()
+ source_vm.qmp('migrate', uri='fd:%s' % opaque)
+ self.assert_migration(source_vm, dest_vm)
--
2.21.1
^ permalink raw reply related
* Re: [PATCH V4 5/5] vdpasim: vDPA device simulator
From: Jason Gunthorpe @ 2020-02-20 15:12 UTC (permalink / raw)
To: Jason Wang
Cc: mst@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
tiwei.bie@intel.com, maxime.coquelin@redhat.com,
cunming.liang@intel.com, zhihong.wang@intel.com,
rob.miller@broadcom.com, xiao.w.wang@intel.com,
haotian.wang@sifive.com, lingshan.zhu@intel.com,
eperezma@redhat.com, lulu@redhat.com
In-Reply-To: <20200220061141.29390-6-jasowang@redhat.com>
On Thu, Feb 20, 2020 at 02:11:41PM +0800, Jason Wang wrote:
> +static void vdpasim_device_release(struct device *dev)
> +{
> + struct vdpasim *vdpasim = dev_to_sim(dev);
> +
> + cancel_work_sync(&vdpasim->work);
> + kfree(vdpasim->buffer);
> + vhost_iotlb_free(vdpasim->iommu);
> + kfree(vdpasim);
> +}
> +
> +static struct vdpasim *vdpasim_create(void)
> +{
> + struct virtio_net_config *config;
> + struct vhost_iotlb *iommu;
> + struct vdpasim *vdpasim;
> + struct device *dev;
> + void *buffer;
> + int ret = -ENOMEM;
> +
> + iommu = vhost_iotlb_alloc(2048, 0);
> + if (!iommu)
> + goto err;
> +
> + buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!buffer)
> + goto err_buffer;
> +
> + vdpasim = kzalloc(sizeof(*vdpasim), GFP_KERNEL);
> + if (!vdpasim)
> + goto err_alloc;
> +
> + vdpasim->buffer = buffer;
> + vdpasim->iommu = iommu;
> +
> + config = &vdpasim->config;
> + config->mtu = 1500;
> + config->status = VIRTIO_NET_S_LINK_UP;
> + eth_random_addr(config->mac);
> +
> + INIT_WORK(&vdpasim->work, vdpasim_work);
> + spin_lock_init(&vdpasim->lock);
> +
> + vringh_set_iotlb(&vdpasim->vqs[0].vring, vdpasim->iommu);
> + vringh_set_iotlb(&vdpasim->vqs[1].vring, vdpasim->iommu);
> +
> + dev = &vdpasim->dev;
> + dev->release = vdpasim_device_release;
> + dev->coherent_dma_mask = DMA_BIT_MASK(64);
> + set_dma_ops(dev, &vdpasim_dma_ops);
> + dev_set_name(dev, "%s", VDPASIM_NAME);
> +
> + ret = device_register(&vdpasim->dev);
> + if (ret)
> + goto err_init;
It is a bit weird to be creating this dummy parent, couldn't this be
done by just passing a NULL parent to vdpa_alloc_device, doing
set_dma_ops() on the vdpasim->vdpa->dev and setting dma_device to
vdpasim->vdpa->dev ?
> + vdpasim->vdpa = vdpa_alloc_device(dev, dev, &vdpasim_net_config_ops);
> + if (ret)
> + goto err_vdpa;
> + ret = vdpa_register_device(vdpasim->vdpa);
> + if (ret)
> + goto err_register;
> +
> + return vdpasim;
> +
> +err_register:
> + put_device(&vdpasim->vdpa->dev);
> +err_vdpa:
> + device_del(&vdpasim->dev);
> + goto err;
> +err_init:
> + put_device(&vdpasim->dev);
> + goto err;
If you do the vdmasim alloc first, and immediately do
device_initialize() then all the failure paths can do put_device
instead of having this ugly goto unwind split. Just check for
vdpasim->iommu == NULL during release.
> +static int __init vdpasim_dev_init(void)
> +{
> + vdpasim_dev = vdpasim_create();
> +
> + if (!IS_ERR(vdpasim_dev))
> + return 0;
> +
> + return PTR_ERR(vdpasim_dev);
> +}
> +
> +static int vdpasim_device_remove_cb(struct device *dev, void *data)
> +{
> + struct vdpa_device *vdpa = dev_to_vdpa(dev);
> +
> + vdpa_unregister_device(vdpa);
> +
> + return 0;
> +}
> +
> +static void __exit vdpasim_dev_exit(void)
> +{
> + device_for_each_child(&vdpasim_dev->dev, NULL,
> + vdpasim_device_remove_cb);
Why the loop? There is only one device, and it is in the global
varaible vdmasim_dev ?
Jason
^ permalink raw reply
* Re: [PATCH V4 5/5] vdpasim: vDPA device simulator
From: Jason Gunthorpe @ 2020-02-20 15:12 UTC (permalink / raw)
To: Jason Wang
Cc: mst@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
tiwei.bie@intel.com, maxime.coquelin@redhat.com,
cunming.liang@intel.com, zhihong.wang@intel.com,
rob.miller@broadcom.com, xiao.w.wang@intel.com,
haotian.wang@sifive.com, lingshan.zhu@intel.com,
eperezma@redhat.com, lulu@redhat.com, Parav Pandit,
kevin.tian@intel.com, stefanha@redhat.com, rdunlap@infradead.org,
hch@infradead.org, aadam@redhat.com, Jiri Pirko, Shahaf Shuler,
hanand@xilinx.com, mhabets@solarflare.com
In-Reply-To: <20200220061141.29390-6-jasowang@redhat.com>
On Thu, Feb 20, 2020 at 02:11:41PM +0800, Jason Wang wrote:
> +static void vdpasim_device_release(struct device *dev)
> +{
> + struct vdpasim *vdpasim = dev_to_sim(dev);
> +
> + cancel_work_sync(&vdpasim->work);
> + kfree(vdpasim->buffer);
> + vhost_iotlb_free(vdpasim->iommu);
> + kfree(vdpasim);
> +}
> +
> +static struct vdpasim *vdpasim_create(void)
> +{
> + struct virtio_net_config *config;
> + struct vhost_iotlb *iommu;
> + struct vdpasim *vdpasim;
> + struct device *dev;
> + void *buffer;
> + int ret = -ENOMEM;
> +
> + iommu = vhost_iotlb_alloc(2048, 0);
> + if (!iommu)
> + goto err;
> +
> + buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!buffer)
> + goto err_buffer;
> +
> + vdpasim = kzalloc(sizeof(*vdpasim), GFP_KERNEL);
> + if (!vdpasim)
> + goto err_alloc;
> +
> + vdpasim->buffer = buffer;
> + vdpasim->iommu = iommu;
> +
> + config = &vdpasim->config;
> + config->mtu = 1500;
> + config->status = VIRTIO_NET_S_LINK_UP;
> + eth_random_addr(config->mac);
> +
> + INIT_WORK(&vdpasim->work, vdpasim_work);
> + spin_lock_init(&vdpasim->lock);
> +
> + vringh_set_iotlb(&vdpasim->vqs[0].vring, vdpasim->iommu);
> + vringh_set_iotlb(&vdpasim->vqs[1].vring, vdpasim->iommu);
> +
> + dev = &vdpasim->dev;
> + dev->release = vdpasim_device_release;
> + dev->coherent_dma_mask = DMA_BIT_MASK(64);
> + set_dma_ops(dev, &vdpasim_dma_ops);
> + dev_set_name(dev, "%s", VDPASIM_NAME);
> +
> + ret = device_register(&vdpasim->dev);
> + if (ret)
> + goto err_init;
It is a bit weird to be creating this dummy parent, couldn't this be
done by just passing a NULL parent to vdpa_alloc_device, doing
set_dma_ops() on the vdpasim->vdpa->dev and setting dma_device to
vdpasim->vdpa->dev ?
> + vdpasim->vdpa = vdpa_alloc_device(dev, dev, &vdpasim_net_config_ops);
> + if (ret)
> + goto err_vdpa;
> + ret = vdpa_register_device(vdpasim->vdpa);
> + if (ret)
> + goto err_register;
> +
> + return vdpasim;
> +
> +err_register:
> + put_device(&vdpasim->vdpa->dev);
> +err_vdpa:
> + device_del(&vdpasim->dev);
> + goto err;
> +err_init:
> + put_device(&vdpasim->dev);
> + goto err;
If you do the vdmasim alloc first, and immediately do
device_initialize() then all the failure paths can do put_device
instead of having this ugly goto unwind split. Just check for
vdpasim->iommu == NULL during release.
> +static int __init vdpasim_dev_init(void)
> +{
> + vdpasim_dev = vdpasim_create();
> +
> + if (!IS_ERR(vdpasim_dev))
> + return 0;
> +
> + return PTR_ERR(vdpasim_dev);
> +}
> +
> +static int vdpasim_device_remove_cb(struct device *dev, void *data)
> +{
> + struct vdpa_device *vdpa = dev_to_vdpa(dev);
> +
> + vdpa_unregister_device(vdpa);
> +
> + return 0;
> +}
> +
> +static void __exit vdpasim_dev_exit(void)
> +{
> + device_for_each_child(&vdpasim_dev->dev, NULL,
> + vdpasim_device_remove_cb);
Why the loop? There is only one device, and it is in the global
varaible vdmasim_dev ?
Jason
^ permalink raw reply
* Re: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
From: Nirmoy @ 2020-02-20 15:15 UTC (permalink / raw)
To: amd-gfx
In-Reply-To: <DM6PR12MB39317F37CBE569725C00ABD284130@DM6PR12MB3931.namprd12.prod.outlook.com>
On 2/20/20 2:35 PM, Liu, Monk wrote:
> Sorry, my previous idea still leave RQ null, please check if below method works:
>
> 29 static struct drm_sched_rq *
> 130 drm_sched_entity_get_free_sched(struct drm_sched_entity *entity)
> 131 {
> 132 struct drm_sched_rq *rq = NULL;
> 133 unsigned int min_jobs = UINT_MAX, num_jobs;
> 134 int i;
>
> 135
> While (!mutex_trylock(....))
> Sleep()
We can't do that drm_sched_entity_get_free_sched is in another
module(drm scheduler) independent of amdgpu
> 136 for (i = 0; i < entity->num_rq_list; ++i) {
> 137 struct drm_gpu_scheduler *sched = entity->rq_list[i]->sched;
> 138
> 139 if (!entity->rq_list[i]->sched->ready) { //we take the gpu reset mutex lock, so now sched->ready won't be set to "not ready"
> 140 DRM_WARN("sched%s is not ready, skipping", sched->name);
> 141 continue;
> 142 }
> 143
> 144 num_jobs = atomic_read(&sched->num_jobs);
> 145 if (num_jobs < min_jobs) {
> 146 min_jobs = num_jobs;
> 147 rq = entity->rq_list[i];
> 148 }
> 149 }
>
> Mutex_unlock(...)
>
> 150
> 151 return rq;
> 152 }
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: 5.4-stable request: 52e29e331070cd ('btrfs: don't set path->leave_spinning for truncate')
From: Holger Hoffstätte @ 2020-02-20 15:12 UTC (permalink / raw)
To: Sasha Levin; +Cc: stable@vger.kernel.org
In-Reply-To: <20200218161426.GM1734@sasha-vm>
Hi Sasha,
On 2/18/20 5:14 PM, Sasha Levin wrote:
> On Tue, Feb 18, 2020 at 01:01:40PM +0100, Holger Hoffstätte wrote:
>> Hi,
>>
>> I was just looking throught the current 5.4-stable queue and saw that
>> 28553fa992cb28 ('Btrfs: fix race between shrinking truncate and fiemap')
>> is queued. Upstream has a follow-up fix for this: 52e29e331070cd aka
>> 'btrfs: don't set path->leave_spinning for truncate'.
>>
>> Would be nice to get those in together. I only looked at 5.4, don't
>> know about other queues.
>
> Since that fix just hit upstream, I'm going to remove 28553fa992cb28
> from the queue now and work on getting both patches in the next release.
Thanks, but maybe wait until [1] has also hit mainline? It's another fix
for 28553fa992cb28.
thanks,
Holger
[1] https://patchwork.kernel.org/patch/11394171/
^ permalink raw reply
* Re: Questions about logic_pio
From: Jiaxun Yang @ 2020-02-20 15:12 UTC (permalink / raw)
To: John Garry
Cc: Wei Xu, bhelgaas, andyshevchenko, Arnd Bergmann, linux-kernel,
Linux Mips
In-Reply-To: <1ebf4461-eb37-ff58-1faf-dd24d83f85cf@huawei.com>
---- 在 星期四, 2020-02-20 22:23:57 John Garry <john.garry@huawei.com> 撰写 ----
> > Also Cc MIPS list to check other's opinions.
> >
> > Hi John.
> >
>
> Hi Jiaxun Yang,
>
> > Thanks for your kind explanation, however, I think this way is
> > violating how I/O ports supposed to work, at least in MIPS world.
>
> For a bit more history, please understand that the core PCI code was
> managing non-native IO port space in the same way before we added the
> logic PIO framework. The only real functional change here was that we
> introduced the indirect-io region within the IO port space, under
> CONFIG_INDIRECT_PIO.
I'm going to do more investigation. Thanks.
>
> >
> > > >>
> > > >> After dig into logic pio logic, I found that logic pio is trying to "allocate" an io_start
> > > >> for MMIO ranges, the allocation starts from 0x0. And later the io_start is used to calculate
> > > >> cpu_address. In my opinion, for direct MMIO access, logic_pio address should always
> > > >> equal to hw address,
> > >
> > > I'm not sure what you mean by simply the hw address.
> > >
> >
> > I meant hw_start should always equal to io_start.
> >
> >
> > MIPS have their own wrapped inl/outl functions,
>
> Can you please point me to these? I could not find them in arch/mips
They are built by __BUILD_IOPORT_PFX(bus, bwlq, type) macro.
Just using mips_io_port_base + offset to handle inl/outl, the same way PCI_IOBASE.
>
> I will also note that arch/mips/include/asm/io.h does not include
> asm-generic io.h today
Yes, and I'm attempting to take advantage of asm-generic.
>
> doing the samething with
> > PCI_IOBASE enabled one. I was just trying to use PCI_IOBASE instead.
> >
> > Originally, the I/O ports layout seems like this:
> >
> > 00000020-00000021 : pic1
> > 00000060-0000006f : i8042
> > 00000070-00000077 : rtc0
> > 000000a0-000000a1 : pic2
> > 00000170-00000177 : pata_atiixp
> > 000001f0-000001f7 : pata_atiixp
> > 00000376-00000376 : pata_atiixp
> > 000003f6-000003f6 : pata_atiixp
> > 00000800-000008ff : acpi
> > 00001000-00001008 : piix4_smbus
> > 00004000-0003ffff : pci io space
> > 00004000-00004fff : PCI Bus 0000:01
> > 00004000-000040ff : 0000:01:05.0
> > 00005000-00005fff : PCI Bus 0000:03
> > 00005000-0000501f : 0000:03:00.0
> >
> > But with PCI_IOBASE defined, I got this:
> >
> > host bridge /bus@10000000/pci@10000000 ranges:
> > MEM 0x0040000000..0x007fffffff -> 0x0040000000
> > IO 0x0000004000..0x0000007fff -> 0x0000004000
> > resource collision: [io 0x0000-0x3fff] conflicts with pic1 [io 0x0020-0x0021]
> >
> > Because io_start was allocated to 0x0 by Logic PIO.
> >
> > There are a lot of devices that have fixed ioports thanks to x86's legacy.
>
> Well, yes, I'm not so surprised.
>
> So if MIPS does not have native IO port access, then surely you need
> some host bridge to translate host CPU MMIO accesses to port I/O
> accesses, right? Where are these CPU addresses defined?
It is defined by the variable mips_io_port_base.
>
> > For example, in my hardware, ioports for RTC, PIC, I8042 are unmoveable,
> > and they can't be managed by logic pio subsystem. > Also, the PCI Hostbridge got implied by DeviceTree that it's I/O range
> > started from 0x4000 in bus side
>
> which bus is this?
They're all located under "ISA Range". Just an MMIO range that will resend
the request to ISA I/O. --ioports for both PCI and some legacy devices.
In that range, base + 0x0000 to 0x4000 is preserved for PIO devices (e.g.) I8259
and base + 0x4000 to MMIO_LIMIT are for PCI devices under host bridge.
For the host bridge, ioports it can decode starts from 0x4000.
My intentional behavior is that when I'm specifying in dts that the IO Range of PCI host
bridge is 0x4000 to 0x7fff, it would request the IO_RESOURCE start from 0x4000
to 0x7fff, also tell the host driver to decode 0x4000 to 0x7fff in IO BAR, And let the drivers
access 0x4000 to 0x7fff via inl/outl, rather than allocate from PIO 0x0 to 0x3fff.
>
> , but then, Logic PIO remapped to PCI_IOBASE + 0x0.
> > The real address should be PCI_IOBASE + 0x4000,
>
> You seem to be using two methods to manage IO port space, and they seem
> to be conflicting.
So... Are there any way to handle these unmoveable devices in logic pio world?
>
> > hardware never got correctly informed about that. And there is still no way to
> > transform to correct address as it's inside the MMIO_LIMIT.
> >
> > So the question comes to why we're allocating io_start for MMIO PCI_IOBASE
> > rather than just check the range provided doesn't overlap each other or exceed
> > the MMIO_LIMIT.
>
> When PCI_IOBASE is defined, we work on the basis that any IO port range
> in the system is registered for a logical PIO region, which manages the
> actual IO port addresses - see logic_pio_trans_cpuaddr().
The port is not the actual port.. It makes me confusing about what it's actually doing..
Sorry but probably I'm still thinking in a vintage way -- need some hints about how to
deal with these legacy cases in a modern way.
Thanks.
>
> Thanks,
> John
>
^ permalink raw reply
* [PATCH v2 1/3] Adding functions _send_fds and _recv_fds
From: Oksana Vohchana @ 2020-02-20 15:10 UTC (permalink / raw)
To: qemu-devel; +Cc: ovoshcha, philmd, ehabkost, wainersm, crosa
In-Reply-To: <20200220151039.20552-1-ovoshcha@redhat.com>
It provides new possibilities to send or receive data through the Unix domain
socket file descriptor.
This is useful for obtaining a socket that belongs to a different network
namespace.
Signed-off-by: Oksana Vohchana <ovoshcha@redhat.com>
---
python/qemu/machine.py | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/python/qemu/machine.py b/python/qemu/machine.py
index 183d8f3d38..976316e5f5 100644
--- a/python/qemu/machine.py
+++ b/python/qemu/machine.py
@@ -24,6 +24,7 @@ import subprocess
import shutil
import socket
import tempfile
+import array
from . import qmp
@@ -155,6 +156,29 @@ class QEMUMachine(object):
self._args.append(','.join(options))
return self
+ def _recv_fds(self, sock, msglen=8192, maxfds=4096):
+ """
+ Function from:
+ https://docs.python.org/3/library/socket.html#socket.socket.recvmsg
+ """
+ fds = array.array("i")
+ msg, ancdata, flags, addr = sock.recvmsg(msglen, socket.CMSG_LEN(
+ maxfds * fds.itemsize))
+ for cmsg_level, cmsg_type, cmsg_data in ancdata:
+ if (cmsg_level == socket.SOL_SOCKET and
+ cmsg_type == socket.SCM_RIGHTS):
+ fds.frombytes(cmsg_data[:len(cmsg_data) - (len(cmsg_data)
+ % fds.itemsize)])
+ return msg, list(fds)
+
+ def _send_fds(self, sock, msg, fds):
+ """
+ Function from:
+ https://docs.python.org/3/library/socket.html#socket.socket.sendmsg
+ """
+ return sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS,
+ array.array("i", fds))])
+
def send_fd_scm(self, fd=None, file_path=None):
"""
Send an fd or file_path to socket_scm_helper.
--
2.21.1
^ permalink raw reply related
* Re: [PATCH 2/4] Btrfs: simplify inline extent handling when doing reflinks
From: Josef Bacik @ 2020-02-20 15:13 UTC (permalink / raw)
To: fdmanana, linux-btrfs
In-Reply-To: <20200219140556.1641567-1-fdmanana@kernel.org>
On 2/19/20 9:05 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> We can not reflink parts of an inline extent, we must always reflink the
> whole inline extent. We know that inline extents always start at file
> offset 0 and that can never represent an amount of data larger then the
> filesystem's sector size (both compressed and uncompressed). We also have
> had the constraints that reflink operations must have a start offset that
> is aligned to the sector size and an end offset that is also aligned or
> it ends the inode's i_size, so there's no way for user space to be able
> to do a reflink operation that will refer to only a part of an inline
> extent.
>
> Initially there was a bug in the inlining code that could allow compressed
> inline extents that encoded more than 1 page, but that was fixed in 2008
> by commit 70b99e6959a4c2 ("Btrfs: Compression corner fixes") since that
> was problematic.
>
> So remove all the extent cloning code that deals with the possibility
> of cloning only partial inline extents.
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* [PATCH v2 2/3] Updates send_fd_scm function
From: Oksana Vohchana @ 2020-02-20 15:10 UTC (permalink / raw)
To: qemu-devel; +Cc: ovoshcha, philmd, ehabkost, wainersm, crosa
In-Reply-To: <20200220151039.20552-1-ovoshcha@redhat.com>
A qemu-iotest uses for FD-migration test a helper program "socket_scm_helper".
And it makes some problems if you didn't build it with a QEMU. And now we can
use new methods for the socket that allow us to send a file/socket descriptor
(with access and permissions) from one process to another.
Signed-off-by: Oksana Vohchana <ovoshcha@redhat.com>
---
python/qemu/machine.py | 64 ++++++++++++++++++++++++++----------------
1 file changed, 40 insertions(+), 24 deletions(-)
diff --git a/python/qemu/machine.py b/python/qemu/machine.py
index 976316e5f5..906ca118db 100644
--- a/python/qemu/machine.py
+++ b/python/qemu/machine.py
@@ -179,20 +179,27 @@ class QEMUMachine(object):
return sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS,
array.array("i", fds))])
- def send_fd_scm(self, fd=None, file_path=None):
+ def send_fd_scm(self, fd=None, file_path=None, data=None):
"""
- Send an fd or file_path to socket_scm_helper.
+ Can be used in two different cases.
+ Send an fd or file_path to socket_scm_helper or
+ provide data and fd to send it to the socket.
- Exactly one of fd and file_path must be given.
- If it is file_path, the helper will open that file and pass its own fd.
+ Exactly one of fd and file_path must be given to the case of
+ socket_scm_helper. If it is file_path, the helper will open that file
+ and pass its own fd.
+
+ To second case need adds data that include a QMP request and fd
"""
# In iotest.py, the qmp should always use unix socket.
assert self._qmp.is_scm_available()
- if self._socket_scm_helper is None:
- raise QEMUMachineError("No path to socket_scm_helper set")
- if not os.path.exists(self._socket_scm_helper):
- raise QEMUMachineError("%s does not exist" %
- self._socket_scm_helper)
+ if data is None:
+ if self._socket_scm_helper is None:
+ raise QEMUMachineError(
+ "No path to socket_scm_helper set or data provided")
+ if not os.path.exists(self._socket_scm_helper):
+ raise QEMUMachineError("%s does not exist" %
+ self._socket_scm_helper)
# This did not exist before 3.4, but since then it is
# mandatory for our purpose
@@ -201,24 +208,33 @@ class QEMUMachine(object):
if fd is not None:
os.set_inheritable(fd, True)
- fd_param = ["%s" % self._socket_scm_helper,
- "%d" % self._qmp.get_sock_fd()]
+ if data is None:
+ fd_param = ["%s" % self._socket_scm_helper,
+ "%d" % self._qmp.get_sock_fd()]
+ if file_path is not None:
+ assert fd is None
+ fd_param.append(file_path)
+ else:
+ assert fd is not None
+ fd_param.append(str(fd))
- if file_path is not None:
- assert fd is None
- fd_param.append(file_path)
- else:
- assert fd is not None
- fd_param.append(str(fd))
+ devnull = open(os.path.devnull, 'rb')
+ proc = subprocess.Popen(fd_param, stdin=devnull,
+ stdout=subprocess.PIPE,
+ stderr=subprocess.STDOUT, close_fds=False)
+ output = proc.communicate()[0]
+ if output:
+ LOG.debug(output)
- devnull = open(os.path.devnull, 'rb')
- proc = subprocess.Popen(fd_param, stdin=devnull, stdout=subprocess.PIPE,
- stderr=subprocess.STDOUT, close_fds=False)
- output = proc.communicate()[0]
- if output:
- LOG.debug(output)
+ return proc.returncode
- return proc.returncode
+ else:
+ sock_fd = socket.fromfd(self._qmp.get_sock_fd(), socket.AF_UNIX,
+ socket.SOCK_STREAM)
+ fds_param = [fd, self._qmp.get_sock_fd()]
+ self._send_fds(sock_fd, data, fds_param)
+ self._recv_fds(sock_fd)
+ return self
@staticmethod
def _remove_if_exists(path):
--
2.21.1
^ permalink raw reply related
* [PATCH 1/2] net: mdio: add ipq8064 mdio driver
From: Ansuel Smith @ 2020-02-20 15:12 UTC (permalink / raw)
Cc: Ansuel Smith, Andy Gross, Bjorn Andersson, David S. Miller,
Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
Heiner Kallweit, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel
Currently ipq806x soc use generi bitbang driver to
comunicate with the gmac ethernet interface.
Add a dedicated driver created by chunkeey to fix this.
Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
---
drivers/net/phy/Kconfig | 8 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-ipq8064.c | 163 +++++++++++++++++++++++++++++++++
3 files changed, 172 insertions(+)
create mode 100644 drivers/net/phy/mdio-ipq8064.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 9dabe03a668c..ec2a5493a7e8 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -157,6 +157,14 @@ config MDIO_I2C
This is library mode.
+config MDIO_IPQ8064
+ tristate "Qualcomm IPQ8064 MDIO interface support"
+ depends on HAS_IOMEM && OF_MDIO
+ depends on MFD_SYSCON
+ help
+ This driver supports the MDIO interface found in the network
+ interface units of the IPQ8064 SoC
+
config MDIO_MOXART
tristate "MOXA ART MDIO interface support"
depends on ARCH_MOXART || COMPILE_TEST
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index fe5badf13b65..8f02bd2089f3 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_MDIO_CAVIUM) += mdio-cavium.o
obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
obj-$(CONFIG_MDIO_HISI_FEMAC) += mdio-hisi-femac.o
obj-$(CONFIG_MDIO_I2C) += mdio-i2c.o
+obj-$(CONFIG_MDIO_IPQ8064) += mdio-ipq8064.o
obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
obj-$(CONFIG_MDIO_MSCC_MIIM) += mdio-mscc-miim.o
obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
diff --git a/drivers/net/phy/mdio-ipq8064.c b/drivers/net/phy/mdio-ipq8064.c
new file mode 100644
index 000000000000..c76e6a647787
--- /dev/null
+++ b/drivers/net/phy/mdio-ipq8064.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Qualcomm IPQ8064 MDIO interface driver
+//
+// Copyright (C) 2019 Christian Lamparter <chunkeey@gmail.com>
+
+#include <linux/delay.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/of_mdio.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/syscon.h>
+
+/* MII address register definitions */
+#define MII_ADDR_REG_ADDR 0x10
+#define MII_BUSY BIT(0)
+#define MII_WRITE BIT(1)
+#define MII_CLKRANGE_60_100M (0 << 2)
+#define MII_CLKRANGE_100_150M (1 << 2)
+#define MII_CLKRANGE_20_35M (2 << 2)
+#define MII_CLKRANGE_35_60M (3 << 2)
+#define MII_CLKRANGE_150_250M (4 << 2)
+#define MII_CLKRANGE_250_300M (5 << 2)
+#define MII_CLKRANGE_MASK GENMASK(4, 2)
+#define MII_REG_SHIFT 6
+#define MII_REG_MASK GENMASK(10, 6)
+#define MII_ADDR_SHIFT 11
+#define MII_ADDR_MASK GENMASK(15, 11)
+
+#define MII_DATA_REG_ADDR 0x14
+
+#define MII_MDIO_DELAY (1000)
+#define MII_MDIO_RETRY (10)
+
+struct ipq8064_mdio {
+ struct regmap *base; /* NSS_GMAC0_BASE */
+};
+
+static int
+ipq8064_mdio_wait_busy(struct ipq8064_mdio *priv)
+{
+ int i;
+
+ for (i = 0; i < MII_MDIO_RETRY; i++) {
+ unsigned int busy;
+
+ regmap_read(priv->base, MII_ADDR_REG_ADDR, &busy);
+ if (!(busy & MII_BUSY))
+ return 0;
+
+ udelay(MII_MDIO_DELAY);
+ }
+
+ return -ETIMEDOUT;
+}
+
+static int
+ipq8064_mdio_read(struct mii_bus *bus, int phy_addr, int reg_offset)
+{
+ struct ipq8064_mdio *priv = bus->priv;
+ u32 miiaddr = MII_BUSY | MII_CLKRANGE_250_300M;
+ u32 ret_val;
+ int err;
+
+ miiaddr |= ((phy_addr << MII_ADDR_SHIFT) & MII_ADDR_MASK) |
+ ((reg_offset << MII_REG_SHIFT) & MII_REG_MASK);
+
+ regmap_write(priv->base, MII_ADDR_REG_ADDR, miiaddr);
+ usleep_range(10, 20);
+
+ err = ipq8064_mdio_wait_busy(priv);
+ if (err)
+ return err;
+
+ regmap_read(priv->base, MII_DATA_REG_ADDR, &ret_val);
+ return (int)ret_val;
+}
+
+static int
+ipq8064_mdio_write(struct mii_bus *bus, int phy_addr, int reg_offset, u16 data)
+{
+ struct ipq8064_mdio *priv = bus->priv;
+ u32 miiaddr = MII_WRITE | MII_BUSY | MII_CLKRANGE_250_300M;
+
+ regmap_write(priv->base, MII_DATA_REG_ADDR, data);
+
+ miiaddr |= ((phy_addr << MII_ADDR_SHIFT) & MII_ADDR_MASK) |
+ ((reg_offset << MII_REG_SHIFT) & MII_REG_MASK);
+
+ regmap_write(priv->base, MII_ADDR_REG_ADDR, miiaddr);
+ usleep_range(10, 20);
+
+ return ipq8064_mdio_wait_busy(priv);
+}
+
+static int
+ipq8064_mdio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct ipq8064_mdio *priv;
+ struct mii_bus *bus;
+ int ret;
+
+ bus = devm_mdiobus_alloc_size(&pdev->dev, sizeof(*priv));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = "ipq8064_mdio_bus";
+ bus->read = ipq8064_mdio_read;
+ bus->write = ipq8064_mdio_write;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mii", dev_name(&pdev->dev));
+ bus->parent = &pdev->dev;
+
+ priv = bus->priv;
+ priv->base = syscon_node_to_regmap(np);
+ if (IS_ERR_OR_NULL(priv->base)) {
+ priv->base = syscon_regmap_lookup_by_phandle(np, "master");
+ if (IS_ERR_OR_NULL(priv->base)) {
+ pr_err("master phandle not found\n");
+ return -EINVAL;
+ }
+ }
+
+ ret = of_mdiobus_register(bus, np);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, bus);
+ return 0;
+}
+
+static int
+ipq8064_mdio_remove(struct platform_device *pdev)
+{
+ struct mii_bus *bus = platform_get_drvdata(pdev);
+
+ mdiobus_unregister(bus);
+
+ return 0;
+}
+
+static const struct of_device_id ipq8064_mdio_dt_ids[] = {
+ { .compatible = "qcom,ipq8064-mdio" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ipq8064_mdio_dt_ids);
+
+static struct platform_driver ipq8064_mdio_driver = {
+ .probe = ipq8064_mdio_probe,
+ .remove = ipq8064_mdio_remove,
+ .driver = {
+ .name = "ipq8064-mdio",
+ .of_match_table = ipq8064_mdio_dt_ids,
+ },
+};
+
+module_platform_driver(ipq8064_mdio_driver);
+
+MODULE_DESCRIPTION("Qualcomm IPQ8064 MDIO interface driver");
+MODULE_AUTHOR("Christian Lamparter <chunkeey@gmail.com>");
+MODULE_LICENSE("GPL");
--
2.25.0
^ permalink raw reply related
* [PATCH 2/2] Documentation: devictree: Add ipq806x mdio bindings
From: Ansuel Smith @ 2020-02-20 15:12 UTC (permalink / raw)
Cc: Ansuel Smith, Andy Gross, Bjorn Andersson, David S. Miller,
Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
Heiner Kallweit, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel
In-Reply-To: <20200220151301.10564-1-ansuelsmth@gmail.com>
Add documentations for ipq806x mdio driver.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
---
.../bindings/net/qcom,ipq8064-mdio.yaml | 52 +++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml
diff --git a/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml
new file mode 100644
index 000000000000..c5a21c0b5325
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qcom,ipq8064-mdio.txt
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm ipq806x MDIO bus controller
+
+description: |+
+ The ipq806x soc have a MDIO dedicated controller that is
+ used to comunicate with the gmac phy conntected.
+ Child nodes of this MDIO bus controller node are standard
+ Ethernet PHY device nodes as described in
+ Documentation/devicetree/bindings/net/phy.txt
+
+allOf:
+ - $ref: "mdio.yaml#"
+
+properties:
+ compatible:
+ const: qcom,ipq8064-mdio
+ reg:
+ maxItems: 1
+ description: address and length of the register set for the device
+ clocks:
+ maxItems: 1
+ description: A reference to the clock supplying the MDIO bus controller
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#address-cells"
+ - "#size-cells"
+
+examples:
+ - |
+ mdio@37000000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compatible = "qcom,ipq8064-mdio", "syscon";
+ reg = <0x37000000 0x200000>;
+ resets = <&gcc GMAC_CORE1_RESET>;
+ reset-names = "stmmaceth";
+ clocks = <&gcc GMAC_CORE1_CLK>;
+
+ switch@10 {
+ compatible = "qca,qca8337";
+ ...
+ }
+ };
\ No newline at end of file
--
2.25.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.