* Re: [PATCH v4 0/4] MIPS: Remote processor driver
From: Matt Redfearn @ 2016-11-09 13:30 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ralf Baechle, Bjorn Andersson, Ohad Ben-Cohen, linux-mips,
linux-remoteproc, Lisa Parratt, LKML, Qais Yousef,
Masahiro Yamada, Paul Gortmaker, Jason Cooper, James Hogan,
Marc Zyngier, Paul Burton, Peter Zijlstra
In-Reply-To: <alpine.DEB.2.20.1611091111041.3501@nanos>
Hi Thomas,
On 09/11/16 10:15, Thomas Gleixner wrote:
> On Wed, 2 Nov 2016, Matt Redfearn wrote:
>> The MIPS remote processor driver allows non-Linux firmware to take
>> control of and execute on one of the systems VPEs. The CPU must be
>> offlined from Linux first. A sysfs interface is created which allows
>> firmware to be loaded and changed at runtime. A full description is
>> available at [1]. An example firmware that can be used with this driver
>> is available at [2].
>>
>> This is useful to allow running bare metal code, or an RTOS, on one or
>> more CPUs while allowing Linux to continue running on those remaining.
> And how is actually guaranteed that these two things are properly seperated
> (memory, devices, interrupts etc.) ?
Memory separation is primarily handled by the remoteproc subsystem,
which will allocate and map memory as required by the firmware, though
because the CPU is executing in kernel mode there is nothing preventing
it accessing anything in the system. But that is of course the same as
any root process which could do the same thing via /dev/mem. One must be
root to offline the CPU from Linux and load firmware to it, so there is
no greater hazard to the system than that firmware running as a root
process within userland.
Separation of devices and interrupts is a system design issue, as this
feature will find use in embedded systems where the system will be
partitioned into Linux and bare metal components. This is done where
there are requirements such as needing to run real time code as well as
Linux, or enforce separation through firmware binaries running
separately to Linux.
This would be useful, for example, for a modem driver running as bare
metal code within one of the system VPEs and providing a virtio-net
interface to the kernel. There would be no kernel driver present for
such a device, therefore there would be no resource conflicts.
There only different thing about the MIPS implementation of remoteproc
is that it turns one of the general purpose Linux CPUs into a remote
processor, rather than there being a separate remote CPU within the SoC,
as is the case with most remoteproc drivers. But unless there is some
form of MMU between that CPU and the system bus, then it will have the
same ability to access all system resources as is the case with this
driver. Again I don't think there is any greater risk to the system here
as there would be with any other remoteproc based system.
>
> We have rejected attempts to do exactly the same thing on x86 in the
> past. There is virtualization and NOHZ_FULL to do it proper and not just
> with a horrible hackery.
There is already a mechanism to do this in the upstream MIPS kernel -
the VPE loader, which has been there 2005 (commit
e01402b115cccb6357f956649487aca2c6f7fbba). One user of the VPE loader
was Lantiq, who used it to load a proprietary modem driver, for which
there is no GPL driver.
What we are proposing here is to move from that MIPS specific mechanism
of running bare metal code to the standardized remoteproc subsystem such
that people wanting to design a MIPS based system with both real time
firmware and general Linux processing tasks may do so using standardized
kernel interfaces.
Thanks,
Matt
>
> Thanks,
>
> tglx
>
>
^ permalink raw reply
* Re: [PATCH v4 0/4] MIPS: Remote processor driver
From: Matt Redfearn @ 2016-11-09 13:30 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ralf Baechle, Bjorn Andersson, Ohad Ben-Cohen, linux-mips,
linux-remoteproc, Lisa Parratt, LKML, Qais Yousef,
Masahiro Yamada, Paul Gortmaker, Jason Cooper, James Hogan,
Marc Zyngier, Paul Burton, Peter Zijlstra
In-Reply-To: <alpine.DEB.2.20.1611091111041.3501@nanos>
Hi Thomas,
On 09/11/16 10:15, Thomas Gleixner wrote:
> On Wed, 2 Nov 2016, Matt Redfearn wrote:
>> The MIPS remote processor driver allows non-Linux firmware to take
>> control of and execute on one of the systems VPEs. The CPU must be
>> offlined from Linux first. A sysfs interface is created which allows
>> firmware to be loaded and changed at runtime. A full description is
>> available at [1]. An example firmware that can be used with this driver
>> is available at [2].
>>
>> This is useful to allow running bare metal code, or an RTOS, on one or
>> more CPUs while allowing Linux to continue running on those remaining.
> And how is actually guaranteed that these two things are properly seperated
> (memory, devices, interrupts etc.) ?
Memory separation is primarily handled by the remoteproc subsystem,
which will allocate and map memory as required by the firmware, though
because the CPU is executing in kernel mode there is nothing preventing
it accessing anything in the system. But that is of course the same as
any root process which could do the same thing via /dev/mem. One must be
root to offline the CPU from Linux and load firmware to it, so there is
no greater hazard to the system than that firmware running as a root
process within userland.
Separation of devices and interrupts is a system design issue, as this
feature will find use in embedded systems where the system will be
partitioned into Linux and bare metal components. This is done where
there are requirements such as needing to run real time code as well as
Linux, or enforce separation through firmware binaries running
separately to Linux.
This would be useful, for example, for a modem driver running as bare
metal code within one of the system VPEs and providing a virtio-net
interface to the kernel. There would be no kernel driver present for
such a device, therefore there would be no resource conflicts.
There only different thing about the MIPS implementation of remoteproc
is that it turns one of the general purpose Linux CPUs into a remote
processor, rather than there being a separate remote CPU within the SoC,
as is the case with most remoteproc drivers. But unless there is some
form of MMU between that CPU and the system bus, then it will have the
same ability to access all system resources as is the case with this
driver. Again I don't think there is any greater risk to the system here
as there would be with any other remoteproc based system.
>
> We have rejected attempts to do exactly the same thing on x86 in the
> past. There is virtualization and NOHZ_FULL to do it proper and not just
> with a horrible hackery.
There is already a mechanism to do this in the upstream MIPS kernel -
the VPE loader, which has been there 2005 (commit
e01402b115cccb6357f956649487aca2c6f7fbba). One user of the VPE loader
was Lantiq, who used it to load a proprietary modem driver, for which
there is no GPL driver.
What we are proposing here is to move from that MIPS specific mechanism
of running bare metal code to the standardized remoteproc subsystem such
that people wanting to design a MIPS based system with both real time
firmware and general Linux processing tasks may do so using standardized
kernel interfaces.
Thanks,
Matt
>
> Thanks,
>
> tglx
>
>
^ permalink raw reply
* Re: [RFC 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio host controller sub-vended by NI
From: Adrian Hunter @ 2016-11-09 13:24 UTC (permalink / raw)
To: Zach Brown, ulf.hansson; +Cc: linux-mmc, linux-kernel
In-Reply-To: <1478635635-14953-3-git-send-email-zach.brown@ni.com>
On 08/11/16 22:07, Zach Brown wrote:
> On NI 9037 boards the max SDIO frequency is limited by trace lengths
> and other layout choices. The max SDIO frequency is stored in an ACPI
> table, as MXFQ.
>
> The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the
> f_max field of the host with it.
>
> Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
> Reviewed-by: Jaeden Amero <jaeden.amero@ni.com>
> Reviewed-by: Josh Cartwright <joshc@ni.com>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
> ---
> drivers/mmc/host/sdhci-pci-core.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
> index c333ce2..4ac7f16 100644
> --- a/drivers/mmc/host/sdhci-pci-core.c
> +++ b/drivers/mmc/host/sdhci-pci-core.c
> @@ -27,6 +27,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/mmc/slot-gpio.h>
> #include <linux/mmc/sdhci-pci-data.h>
> +#include <linux/acpi.h>
>
> #include "sdhci.h"
> #include "sdhci-pci.h"
> @@ -377,6 +378,35 @@ static int byt_emmc_probe_slot(struct sdhci_pci_slot *slot)
>
> static int ni_byt_sdio_probe_slot(struct sdhci_pci_slot *slot)
> {
> +#ifdef CONFIG_ACPI
> + /* Get max freq from ACPI for NI hardware */
> + acpi_handle acpi_hdl;
> + acpi_status status;
> + struct acpi_buffer acpi_result = {
> + ACPI_ALLOCATE_BUFFER, NULL };
> + union acpi_object *acpi_buffer;
> + int max_freq;
> +
> + status = acpi_get_handle(ACPI_HANDLE(&slot->chip->pdev->dev), "MXFQ",
> + &acpi_hdl);
Is "MXFQ" an object that has already been deployed or are you inventing it
now? In the latter case, did you consider device properties as an alternative?
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + status = acpi_evaluate_object(acpi_hdl, NULL,
> + NULL, &acpi_result);
> + if (ACPI_FAILURE(status))
> + return -EINVAL;
> +
> + acpi_buffer = (union acpi_object *)acpi_result.pointer;
> +
> + if (acpi_buffer->type != ACPI_TYPE_INTEGER)
> + return -EINVAL;
> +
> + max_freq = acpi_buffer->integer.value;
> +
> + slot->host->mmc->f_max = max_freq * 1000000;
> +#endif
> +
> slot->host->mmc->caps |= MMC_CAP_POWER_OFF_CARD | MMC_CAP_NONREMOVABLE;
> return 0;
> }
>
^ permalink raw reply
* [bug report] [media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
From: Dan Carpenter @ 2016-11-09 13:28 UTC (permalink / raw)
To: tiffany.lin; +Cc: linux-media, linux-mediatek
Hello Tiffany Lin,
The patch 590577a4e525: "[media] vcodec: mediatek: Add Mediatek V4L2
Video Decoder Driver" from Sep 2, 2016, leads to the following static
checker warning:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:536 vidioc_vdec_qbuf()
error: buffer overflow 'vq->bufs' 32 <= u32max
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
520 static int vidioc_vdec_qbuf(struct file *file, void *priv,
521 struct v4l2_buffer *buf)
522 {
523 struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
524 struct vb2_queue *vq;
525 struct vb2_buffer *vb;
526 struct mtk_video_dec_buf *mtkbuf;
527 struct vb2_v4l2_buffer *vb2_v4l2;
528
529 if (ctx->state == MTK_STATE_ABORT) {
530 mtk_v4l2_err("[%d] Call on QBUF after unrecoverable error",
531 ctx->id);
532 return -EIO;
533 }
534
535 vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
536 vb = vq->bufs[buf->index];
Smatch thinks that "buf->index" comes straight from the user without
being checked and that this is a buffer overflow. It seems simple
enough to analyse the call tree.
__video_do_ioctl()
-> v4l_qbuf()
-> vidioc_vdec_qbuf()
It seems like Smatch is correct. I looked at a different implementation
of this and that one wasn't checked either so maybe there is something
I am not seeing.
This has obvious security implications. Can someone take a look at
this?
537 vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
538 mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
539
540 if ((buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
541 (buf->m.planes[0].bytesused == 0)) {
542 mtkbuf->lastframe = true;
543 mtk_v4l2_debug(1, "[%d] (%d) id=%d lastframe=%d (%d,%d, %d) vb=%p",
544 ctx->id, buf->type, buf->index,
545 mtkbuf->lastframe, buf->bytesused,
546 buf->m.planes[0].bytesused, buf->length,
547 vb);
548 }
549
550 return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
551 }
regards,
dan carpenter
^ permalink raw reply
* [PATCH V2 4/4] soc/tegra: pmc: Make configuration of IO pads in atomic context
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696962-11831-1-git-send-email-ldewangan@nvidia.com>
The IO pad voltage configuration can be done in the regulator
notifier callback which is atomic in nature.
Replace the mutex with spin lock for the locking mechanism.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
New in series based on pinctrl driver requirement.
---
drivers/soc/tegra/pmc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 916a94b..52cd218 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -172,6 +172,7 @@ struct tegra_pmc_soc {
* @lp0_vec_size: size of the LP0 warm boot code
* @powergates_available: Bitmap of available power gates
* @powergates_lock: mutex for power gate register access
+ * @io_pad_lock: Spinlock for IO pad voltage register access
* @plat_subdevs: Platform device for PMC child devices.
*/
struct tegra_pmc {
@@ -199,6 +200,7 @@ struct tegra_pmc {
DECLARE_BITMAP(powergates_available, TEGRA_POWERGATE_MAX);
struct mutex powergates_lock;
+ struct spinlock io_pad_lock;
struct platform_device **plat_subdevs;
};
@@ -1103,7 +1105,7 @@ int tegra_io_pad_set_voltage(enum tegra_io_pad id,
if (pad->voltage == UINT_MAX)
return -ENOTSUPP;
- mutex_lock(&pmc->powergates_lock);
+ spin_lock(&pmc->io_pad_lock);
/* write-enable PMC_PWR_DET_VALUE[pad->voltage] */
value = tegra_pmc_readl(PMC_PWR_DET);
@@ -1120,7 +1122,7 @@ int tegra_io_pad_set_voltage(enum tegra_io_pad id,
tegra_pmc_writel(value, PMC_PWR_DET_VALUE);
- mutex_unlock(&pmc->powergates_lock);
+ spin_unlock(&pmc->io_pad_lock);
usleep_range(100, 250);
@@ -1800,6 +1802,7 @@ static int __init tegra_pmc_early_init(void)
u32 value;
mutex_init(&pmc->powergates_lock);
+ spin_lock_init(&pmc->io_pad_lock);
np = of_find_matching_node_and_match(NULL, tegra_pmc_match, &match);
if (!np) {
--
2.1.4
^ permalink raw reply related
* [PATCH V2 1/4] soc/tegra: pmc: Remove legacy Tegra I/O rail API
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696962-11831-1-git-send-email-ldewangan@nvidia.com>
Remove tegra_io_rail_power_on() and tegra_io_rail_power_off()
from header as client has been moved to new APIs.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
None
---
include/soc/tegra/pmc.h | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/include/soc/tegra/pmc.h b/include/soc/tegra/pmc.h
index 52780a77..9c314a6 100644
--- a/include/soc/tegra/pmc.h
+++ b/include/soc/tegra/pmc.h
@@ -203,16 +203,6 @@ static inline int tegra_io_pad_get_voltage(enum tegra_io_pad id)
{
return -ENOSYS;
}
-
-static inline int tegra_io_rail_power_on(unsigned int id)
-{
- return -ENOSYS;
-}
-
-static inline int tegra_io_rail_power_off(unsigned int id)
-{
- return -ENOSYS;
-}
#endif /* CONFIG_ARCH_TEGRA */
#endif /* __SOC_TEGRA_PMC_H__ */
--
2.1.4
^ permalink raw reply related
* [PATCH V2 2/4] soc/tegra: pmc: Add interface to get IO pad power status
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696962-11831-1-git-send-email-ldewangan@nvidia.com>
Add API to get the IO pad power status of the Tegra IO pads.
This will help client driver to get the current power status
of IO pads for handling IO pad power.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
None
---
drivers/soc/tegra/pmc.c | 22 ++++++++++++++++++++++
include/soc/tegra/pmc.h | 6 ++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index bb3715f..44546bd 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -1063,6 +1063,28 @@ int tegra_io_pad_power_disable(enum tegra_io_pad id)
}
EXPORT_SYMBOL(tegra_io_pad_power_disable);
+int tegra_io_pad_power_get_status(enum tegra_io_pad id)
+{
+ const struct tegra_io_pad_soc *pad;
+ unsigned long status;
+ u32 value;
+ int bit;
+
+ pad = tegra_io_pad_find(pmc, id);
+ if (!pad)
+ return -ENOENT;
+
+ if (pad->dpd == UINT_MAX)
+ return -ENOTSUPP;
+
+ status = (pad->dpd < 32) ? IO_DPD_STATUS : IO_DPD2_STATUS;
+ bit = pad->dpd % 32;
+ value = tegra_pmc_readl(status);
+
+ return !!(value & BIT(bit));
+}
+EXPORT_SYMBOL(tegra_io_pad_power_get_status);
+
int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage)
{
diff --git a/include/soc/tegra/pmc.h b/include/soc/tegra/pmc.h
index 9c314a6..18cf172 100644
--- a/include/soc/tegra/pmc.h
+++ b/include/soc/tegra/pmc.h
@@ -152,6 +152,7 @@ int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
int tegra_io_pad_power_enable(enum tegra_io_pad id);
int tegra_io_pad_power_disable(enum tegra_io_pad id);
+int tegra_io_pad_power_get_status(enum tegra_io_pad id);
int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage);
int tegra_io_pad_get_voltage(enum tegra_io_pad id);
@@ -193,6 +194,11 @@ static inline int tegra_io_pad_power_disable(enum tegra_io_pad id)
return -ENOSYS;
}
+static inline int tegra_io_pad_power_get_status(enum tegra_io_pad id)
+{
+ return -ENOSYS;
+}
+
static inline int tegra_io_pad_set_voltage(enum tegra_io_pad id,
enum tegra_io_pad_voltage voltage)
{
--
2.1.4
^ permalink raw reply related
* [bug report] [media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
From: Dan Carpenter @ 2016-11-09 13:28 UTC (permalink / raw)
To: tiffany.lin-NuS5LvNUpcJWk0Htik3J/w
Cc: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA
Hello Tiffany Lin,
The patch 590577a4e525: "[media] vcodec: mediatek: Add Mediatek V4L2
Video Decoder Driver" from Sep 2, 2016, leads to the following static
checker warning:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:536 vidioc_vdec_qbuf()
error: buffer overflow 'vq->bufs' 32 <= u32max
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
520 static int vidioc_vdec_qbuf(struct file *file, void *priv,
521 struct v4l2_buffer *buf)
522 {
523 struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
524 struct vb2_queue *vq;
525 struct vb2_buffer *vb;
526 struct mtk_video_dec_buf *mtkbuf;
527 struct vb2_v4l2_buffer *vb2_v4l2;
528
529 if (ctx->state == MTK_STATE_ABORT) {
530 mtk_v4l2_err("[%d] Call on QBUF after unrecoverable error",
531 ctx->id);
532 return -EIO;
533 }
534
535 vq = v4l2_m2m_get_vq(ctx->m2m_ctx, buf->type);
536 vb = vq->bufs[buf->index];
Smatch thinks that "buf->index" comes straight from the user without
being checked and that this is a buffer overflow. It seems simple
enough to analyse the call tree.
__video_do_ioctl()
-> v4l_qbuf()
-> vidioc_vdec_qbuf()
It seems like Smatch is correct. I looked at a different implementation
of this and that one wasn't checked either so maybe there is something
I am not seeing.
This has obvious security implications. Can someone take a look at
this?
537 vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
538 mtkbuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, vb);
539
540 if ((buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
541 (buf->m.planes[0].bytesused == 0)) {
542 mtkbuf->lastframe = true;
543 mtk_v4l2_debug(1, "[%d] (%d) id=%d lastframe=%d (%d,%d, %d) vb=%p",
544 ctx->id, buf->type, buf->index,
545 mtkbuf->lastframe, buf->bytesused,
546 buf->m.planes[0].bytesused, buf->length,
547 vb);
548 }
549
550 return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
551 }
regards,
dan carpenter
^ permalink raw reply
* [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Cao jin @ 2016-11-09 13:28 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <CAKgT0UeaoGfOOC1=h4pGk+=FDd5EqvgRGAdk1StLuiW1-M8tVA@mail.gmail.com>
Thanks Corrina for your info.
I tested my patch, it works for me on kernel 4.9-rc4.
"surprise removal" maybe another issue to solve. This one is enough to
solve my issue and other one's, could it be accept first?
Cao jin
On 11/09/2016 03:33 AM, Alexander Duyck wrote:
> On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
>> On Nov 8 09:16, Hisashi T Fujinaka wrote:
>>> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
>>>> On Nov 8 15:06, Cao jin wrote:
>>>>> When running as guest, under certain condition, it will oops as following.
>>>>> writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
>>>>> is NULL. While other register access won't oops kernel because they use
>>>>> wr32/rd32 which have a defense against NULL pointer.
>>>>> [...]
>>>>
>>>> Incidentally we're just looking for a solution to that problem too.
>>>> Do three patches to fix the same problem at rougly the same time already
>>>> qualify as freak accident?
>>>>
>>>> FTR, I attached my current patch, which I was planning to submit after
>>>> some external testing.
>>>>
>>>> However, all three patches have one thing in common: They workaround
>>>> a somewhat dubious resetting of the hardware address to NULL in case
>>>> reading from a register failed.
>>>>
>>>> That makes me wonder if setting the hardware address to NULL in
>>>> rd32/igb_rd32 is really such a good idea. It's performed in a function
>>>> which return value is *never* tested for validity in the calling
>>>> functions and leads to subsequent crashes since no tests for hw_addr ==
>>>> NULL are performed.
>>>>
>>>> Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
>>>> graceful way to handle the "surprise removal"?
>>>
>>> Answering this from my home account because, well, work is Outlook.
>>>
>>> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
>>> uncertain that the surprise removal code actually works the way I
>>> thought previously and I think I took a lot of it out of my local code.
>>>
>>> Unfortuantely I don't have any equipment that I can use to reproduce
>>> surprise removal any longer so that means I wouldn't be able to test
>>> anything. I have to defer to you or Cao Jin.
>>
>> I'm not too keen to rip out a PCIe NIC under power from my locale
>> desktop machine, but I think an actual surprise removal is not the
>> problem.
>>
>> As described in my git log entry, the error condition in igb_rd32 can be
>> triggered during a suspend. The HW has been put into a sleep state but
>> some register read requests are apparently not guarded against that
>> situation. Reading a register in this state returns -1, thus a suspend
>> is erroneously triggering the "surprise removal" sequence.
>
> The question I would have is what is reading the device when it is in
> this state. The watchdog and any other functions that would read the
> device should be disabled.
>
> One possibility could be a race between a call to igb_close and the
> igb_suspend function. We have seen some of those pop up recently on
> ixgbe and it looks like igb has the same bug. We should probably be
> using the rtnl_lock to guarantee that netif_device_detach and the call
> to __igb_close are completed before igb_close could possibly be called
> by the network stack.
>
>> Here's a raw idea:
>>
>> - Note that device is suspended in e1000_hw struct. Don't trigger
>> error sequence in igb_rd32 if so (...and return a 0 value???)
>
> The thing is that a suspended device should not be accessed at all.
> If we are accessing it while it is suspended then that is a bug. If
> you could throw a WARN_ON call in igb_rd32 to capture where this is
> being triggered that might be useful.
>
>> - Otherwise assume it's actually a surprise removal. In theory that
>> should somehow trigger a device removal sequence, kind of like
>> calling igb_remove, no?
>
> Well a read of the MMIO region while suspended is more of a surprise
> read since there shouldn't be anything going on. We need to isolate
> where that read is coming from and fix it.
>
> Thanks.
>
> - Alex
>
>
> .
>
^ permalink raw reply
* [Buildroot] [PATCH 1/1] olimex_a20_olinuxino_lime2: dump U-Boot to 2016.05
From: Jan Viktorin @ 2016-11-09 13:27 UTC (permalink / raw)
To: buildroot
The patch fixes build by GCC 5 (unsupported by the older U-Boot).
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
configs/olimex_a20_olinuxino_lime2_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/olimex_a20_olinuxino_lime2_defconfig b/configs/olimex_a20_olinuxino_lime2_defconfig
index 57dda72..87fc674 100644
--- a/configs/olimex_a20_olinuxino_lime2_defconfig
+++ b/configs/olimex_a20_olinuxino_lime2_defconfig
@@ -25,7 +25,7 @@ BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BOARDNAME="A20-OLinuXino-Lime2"
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2015.01"
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.05"
BR2_TARGET_UBOOT_SPL=y
BR2_TARGET_UBOOT_SPL_NAME="u-boot-sunxi-with-spl.bin"
BR2_PACKAGE_HOST_GENIMAGE=y
--
2.9.3
^ permalink raw reply related
* [PATCH] serial: 8250_pxa: hide early console setup when disabled
From: Arnd Bergmann @ 2016-11-09 13:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Jiri Slaby, Robert Jarzmik, linux-serial,
linux-kernel
The newly added pxa glue driver for 8250 supports console output, but
fails to build if the 8250 console is disabled:
drivers/tty/serial/8250/8250_pxa.o: In function `early_serial_pxa_setup':
8250_pxa.c:(.init.text+0x50): undefined reference to `early_serial8250_setup'
This adds an #ifdef like the other glue drivers have it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/tty/serial/8250/8250_pxa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_pxa.c b/drivers/tty/serial/8250/8250_pxa.c
index 31f27d95d8b4..4d68731af534 100644
--- a/drivers/tty/serial/8250/8250_pxa.c
+++ b/drivers/tty/serial/8250/8250_pxa.c
@@ -170,6 +170,7 @@ static struct platform_driver serial_pxa_driver = {
module_platform_driver(serial_pxa_driver);
+#ifdef CONFIG_SERIAL_8250_CONSOLE
static int __init early_serial_pxa_setup(struct earlycon_device *device,
const char *options)
{
@@ -182,6 +183,7 @@ static int __init early_serial_pxa_setup(struct earlycon_device *device,
return early_serial8250_setup(device, NULL);
}
OF_EARLYCON_DECLARE(early_pxa, "mrvl,pxa-uart", early_serial_pxa_setup);
+#endif
MODULE_AUTHOR("Sergei Ianovich");
MODULE_LICENSE("GPL");
--
2.9.0
^ permalink raw reply related
* [PATCH v2] MIPS: mm: Fix output of __do_page_fault
From: Matt Redfearn @ 2016-11-09 13:26 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, Matt Redfearn, Paul Gortmaker, linux-kernel,
Kirill A. Shutemov, Andrew Morton
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from __do_page_fault on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont
to provide the appropriate markers & restore the expected output.
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
---
arch/mips/mm/fault.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index d56a855828c2..3bef306cdfdb 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -209,17 +209,18 @@ static void __kprobes __do_page_fault(struct pt_regs *regs, unsigned long write,
if (show_unhandled_signals &&
unhandled_signal(tsk, SIGSEGV) &&
__ratelimit(&ratelimit_state)) {
- pr_info("\ndo_page_fault(): sending SIGSEGV to %s for invalid %s %0*lx",
+ pr_info("do_page_fault(): sending SIGSEGV to %s for invalid %s %0*lx\n",
tsk->comm,
write ? "write access to" : "read access from",
field, address);
pr_info("epc = %0*lx in", field,
(unsigned long) regs->cp0_epc);
- print_vma_addr(" ", regs->cp0_epc);
+ print_vma_addr(KERN_CONT " ", regs->cp0_epc);
+ pr_cont("\n");
pr_info("ra = %0*lx in", field,
(unsigned long) regs->regs[31]);
- print_vma_addr(" ", regs->regs[31]);
- pr_info("\n");
+ print_vma_addr(KERN_CONT " ", regs->regs[31]);
+ pr_cont("\n");
}
current->thread.trap_nr = (regs->cp0_cause >> 2) & 0x1f;
info.si_signo = SIGSEGV;
--
2.7.4
^ permalink raw reply related
* [PATCH v2] MIPS: mm: Fix output of __do_page_fault
From: Matt Redfearn @ 2016-11-09 13:26 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, Matt Redfearn, Paul Gortmaker, linux-kernel,
Kirill A. Shutemov, Andrew Morton
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from __do_page_fault on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont
to provide the appropriate markers & restore the expected output.
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
---
arch/mips/mm/fault.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index d56a855828c2..3bef306cdfdb 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -209,17 +209,18 @@ static void __kprobes __do_page_fault(struct pt_regs *regs, unsigned long write,
if (show_unhandled_signals &&
unhandled_signal(tsk, SIGSEGV) &&
__ratelimit(&ratelimit_state)) {
- pr_info("\ndo_page_fault(): sending SIGSEGV to %s for invalid %s %0*lx",
+ pr_info("do_page_fault(): sending SIGSEGV to %s for invalid %s %0*lx\n",
tsk->comm,
write ? "write access to" : "read access from",
field, address);
pr_info("epc = %0*lx in", field,
(unsigned long) regs->cp0_epc);
- print_vma_addr(" ", regs->cp0_epc);
+ print_vma_addr(KERN_CONT " ", regs->cp0_epc);
+ pr_cont("\n");
pr_info("ra = %0*lx in", field,
(unsigned long) regs->regs[31]);
- print_vma_addr(" ", regs->regs[31]);
- pr_info("\n");
+ print_vma_addr(KERN_CONT " ", regs->regs[31]);
+ pr_cont("\n");
}
current->thread.trap_nr = (regs->cp0_cause >> 2) & 0x1f;
info.si_signo = SIGSEGV;
--
2.7.4
^ permalink raw reply related
* Re: krogoth 2.1.2 status
From: Joshua Lock @ 2016-11-09 13:26 UTC (permalink / raw)
To: Richard Purdie, openembedded-core, Armin Kuster
In-Reply-To: <1478694607.23123.176.camel@linuxfoundation.org>
On Wed, 2016-11-09 at 12:30 +0000, Richard Purdie wrote:
> I ran a krogoth 2.1.2 build. It did have some issues:
>
> * one runtime sanity test had a timeout issue
> * some urls are stale (perpetual problem)
> * musl runtime testing fails (never tested on krogoth previously)
> * no-x11 runtime testing had a failure (never tested on krogoth
> previously)
We can update the autobuilder not to run these tests for krogoth.
I've filed a bug for musl:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10634
for no-x11 there's a single failure, it might be worthwhile backporting
fixes to make that work?
Regards,
Joshua
^ permalink raw reply
* Re: [PATCH v3][manpages 1/2] perf_event_open.2: Document PERF_EVENT_IOC_PAUSE_OUTPUT
From: Michael Kerrisk (man-pages) @ 2016-11-09 13:26 UTC (permalink / raw)
To: Wang Nan, vincent.weaver
Cc: mtk.manpages, pi3orama, linux-kernel, lizefan, linux-man
In-Reply-To: <20161024065256.160703-2-wangnan0@huawei.com>
Hello Wang Nan,
On 10/24/2016 08:52 AM, Wang Nan wrote:
> Linux 4.7 (86e7972f690c1017fd086cdfe53d8524e68c661c) introduces
> PERF_EVENT_IOC_PAUSE_OUTPUT feature. Document it.
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Reviewed-by: Vince Weaver <vincent.weaver@maine.edu>
> Cc: Michael Kerrisk <mtk.manpages@gmail.com>
> ---
> man2/perf_event_open.2 | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
> index fade28c..561331c 100644
> --- a/man2/perf_event_open.2
> +++ b/man2/perf_event_open.2
> @@ -1687,6 +1687,15 @@ the
> .I data_tail
> value should be written by user space to reflect the last read data.
> In this case, the kernel will not overwrite unread data.
> +
> +When the mapping is read only (without
> +.BR PROT_WRITE ),
> +setting .I data_tail is not allowed.
Missing line breaks in the preceding line.
> +In this case, the kernel will overwrite data when sample coming, unless
I find that last line hard to understand.
s/sample coming/a sample arrives/?
> +the ring buffer is paused by a
> +.BR PERF_EVENT_IOC_PAUSE_OUTPUT
> +.BR ioctl (2)
> +system call before reading.
> .TP
> .IR data_offset " (since Linux 4.1)"
> .\" commit e8c6deac69629c0cb97c3d3272f8631ef17f8f0f
> @@ -2865,6 +2874,21 @@ The argument is a BPF program file descriptor that was created by
> a previous
> .BR bpf (2)
> system call.
> +.TP
> +.BR PERF_EVENT_IOC_PAUSE_OUTPUT " (since Linux 4.7)"
> +.\" commit 86e7972f690c1017fd086cdfe53d8524e68c661c
> +This allows pausing and resuming the event's ring-buffer. A
> +paused ring-buffer does not prevent generation of samples, but simply
> +discards the samples. The discarded samples are considered lost,
> +causing
> +.BR PERF_RECORD_LOST
> +to be generated when possible.
> +
> +The argument is an integer. A nonzero value pauses the ring-buffer,
> +zero resumes the ring-buffer.
> +
> +Pausing a read only ring buffer before reading from it without having
> +to worry about data being overwritten.
That last sentence seems incomplete. I can't understand what you
mean here?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* [PATCH V2 3/4] soc/tegra: pmc: Register PMC child devices as platform device
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
In-Reply-To: <1478696962-11831-1-git-send-email-ldewangan@nvidia.com>
Power Management Controller(PMC) of Tegra does the multiple chip
power management related functionality for internal and IO interfacing.
Some of the functionalities are power gating of IP blocks, IO pads
voltage and power state configuration, system power state configurations,
wakeup controls etc.
Different functionalities of the PMC are provided through different
framework like IO pads control can be provided through pinctrl framework,
IO power control is via misc driver etc. All sub functionalities are
represented as PMC child devices.
Register the PMC child devices as platform device and fill the child
devices table for Tegra124 and Tegra210.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
None
---
drivers/soc/tegra/pmc.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 44546bd..916a94b 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -145,6 +145,9 @@ struct tegra_pmc_soc {
const struct tegra_io_pad_soc *io_pads;
unsigned int num_io_pads;
+
+ const char **sub_devs_name;
+ unsigned int num_sub_devs;
};
/**
@@ -169,6 +172,7 @@ struct tegra_pmc_soc {
* @lp0_vec_size: size of the LP0 warm boot code
* @powergates_available: Bitmap of available power gates
* @powergates_lock: mutex for power gate register access
+ * @plat_subdevs: Platform device for PMC child devices.
*/
struct tegra_pmc {
struct device *dev;
@@ -195,6 +199,7 @@ struct tegra_pmc {
DECLARE_BITMAP(powergates_available, TEGRA_POWERGATE_MAX);
struct mutex powergates_lock;
+ struct platform_device **plat_subdevs;
};
static struct tegra_pmc *pmc = &(struct tegra_pmc) {
@@ -1375,6 +1380,43 @@ static void tegra_pmc_init_tsense_reset(struct tegra_pmc *pmc)
of_node_put(np);
}
+static int tegra_pmc_init_sub_devs(struct tegra_pmc *pmc)
+{
+ int ret, i;
+
+ if (!pmc->soc->num_sub_devs)
+ return 0;
+
+ pmc->plat_subdevs = devm_kzalloc(pmc->dev, pmc->soc->num_sub_devs *
+ sizeof(**pmc->plat_subdevs),
+ GFP_KERNEL);
+ if (!pmc->plat_subdevs)
+ return -ENOMEM;
+
+ for (i = 0; i < pmc->soc->num_sub_devs; ++i) {
+ pmc->plat_subdevs[i] = platform_device_register_data(pmc->dev,
+ pmc->soc->sub_devs_name[i],
+ 0, NULL, 0);
+ if (IS_ERR(pmc->plat_subdevs[i])) {
+ ret = PTR_ERR(pmc->plat_subdevs[i]);
+ dev_err(pmc->dev,
+ "Failed to register platform device for %s: %d\n",
+ pmc->soc->sub_devs_name[i], ret);
+ goto pdev_cleanups;
+ }
+ }
+
+ return 0;
+
+pdev_cleanups:
+ while (--i >= 0) {
+ platform_device_unregister(pmc->plat_subdevs[i]);
+ pmc->plat_subdevs[i] = NULL;
+ }
+
+ return ret;
+}
+
static int tegra_pmc_probe(struct platform_device *pdev)
{
void __iomem *base;
@@ -1426,6 +1468,11 @@ static int tegra_pmc_probe(struct platform_device *pdev)
return err;
}
+ err = tegra_pmc_init_sub_devs(pmc);
+ if (err < 0)
+ dev_warn(pmc->dev, "Failed to register PMC sub devices: %d\n",
+ err);
+
mutex_lock(&pmc->powergates_lock);
iounmap(pmc->base);
pmc->base = base;
@@ -1608,6 +1655,10 @@ static const struct tegra_io_pad_soc tegra124_io_pads[] = {
{ .id = TEGRA_IO_PAD_USB_BIAS, .dpd = 12, .voltage = UINT_MAX },
};
+static const char *tegra124_sub_devs_name[] = {
+ "pinctrl-t124-io-pad",
+};
+
static const struct tegra_pmc_soc tegra124_pmc_soc = {
.num_powergates = ARRAY_SIZE(tegra124_powergates),
.powergates = tegra124_powergates,
@@ -1617,6 +1668,8 @@ static const struct tegra_pmc_soc tegra124_pmc_soc = {
.has_gpu_clamps = true,
.num_io_pads = ARRAY_SIZE(tegra124_io_pads),
.io_pads = tegra124_io_pads,
+ .sub_devs_name = tegra124_sub_devs_name,
+ .num_sub_devs = ARRAY_SIZE(tegra124_sub_devs_name),
};
static const char * const tegra210_powergates[] = {
@@ -1694,6 +1747,10 @@ static const struct tegra_io_pad_soc tegra210_io_pads[] = {
{ .id = TEGRA_IO_PAD_USB_BIAS, .dpd = 12, .voltage = UINT_MAX },
};
+static const char *tegra210_sub_devs_name[] = {
+ "pinctrl-t210-io-pad",
+};
+
static const struct tegra_pmc_soc tegra210_pmc_soc = {
.num_powergates = ARRAY_SIZE(tegra210_powergates),
.powergates = tegra210_powergates,
@@ -1703,6 +1760,8 @@ static const struct tegra_pmc_soc tegra210_pmc_soc = {
.has_gpu_clamps = true,
.num_io_pads = ARRAY_SIZE(tegra210_io_pads),
.io_pads = tegra210_io_pads,
+ .sub_devs_name = tegra210_sub_devs_name,
+ .num_sub_devs = ARRAY_SIZE(tegra210_sub_devs_name),
};
static const struct of_device_id tegra_pmc_match[] = {
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: sound: document axentia,tse850-pcm5142 bindings
From: Mark Brown @ 2016-11-09 13:25 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Liam Girdwood, Rob Herring, Mark Rutland,
Jaroslav Kysela, Takashi Iwai, alsa-devel, devicetree
In-Reply-To: <1478622057-12426-2-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
On Tue, Nov 08, 2016 at 05:20:56PM +0100, Peter Rosin wrote:
> The TSE-850 is an FM Transmitter Station Equipment, designed to generate
> baseband signals for FM, mainly the DARC subcarrier, but other signals
> are also possible.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH V2 0/4] soc/tegra: pmc: Add support for IO pad configuration and sub-driver
From: Laxman Dewangan @ 2016-11-09 13:09 UTC (permalink / raw)
To: thierry.reding, swarren
Cc: gnurou, jonathanh, linux-tegra, linux-kernel, Laxman Dewangan
Tegra SoC support the configutaion of IO pads to multi-level voltage
and low power state. The conifguration is done via pictrl framework
and the io pad driver in pinctrl frameowrk uses the APIs from pmc to
access PMC registers.
his series add the API to get the IO pad power status and register
the pmc child devices like IO pad drvier.
The patches were send earlier part of different series but applied
partially in the Thierry's t186 branch
https://github.com/thierryreding/linux/tree/tegra186.
Resending the patches as the new start to avoid any confusion.
This need to be applied in
https://github.com/thierryreding/linux/tree/tegra186
---
Changes from V1:
- make the IO pad votlage configurations to the atomic context as 4th patch of
series.
Laxman Dewangan (4):
soc/tegra: pmc: Remove legacy Tegra I/O rail API
soc/tegra: pmc: Add interface to get IO pad power status
soc/tegra: pmc: Register PMC child devices as platform device
soc/tegra: pmc: Make configuration of IO pads in atomic context
drivers/soc/tegra/pmc.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++--
include/soc/tegra/pmc.h | 14 +++-----
2 files changed, 91 insertions(+), 11 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Cao jin @ 2016-11-09 13:28 UTC (permalink / raw)
To: Alexander Duyck, Hisashi T Fujinaka, Netdev, intel-wired-lan,
linux-kernel@vger.kernel.org, Izumi, Taku/泉 拓,
vinschen
In-Reply-To: <CAKgT0UeaoGfOOC1=h4pGk+=FDd5EqvgRGAdk1StLuiW1-M8tVA@mail.gmail.com>
Thanks Corrina for your info.
I tested my patch, it works for me on kernel 4.9-rc4.
"surprise removal" maybe another issue to solve. This one is enough to
solve my issue and other one's, could it be accept first?
Cao jin
On 11/09/2016 03:33 AM, Alexander Duyck wrote:
> On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
>> On Nov 8 09:16, Hisashi T Fujinaka wrote:
>>> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
>>>> On Nov 8 15:06, Cao jin wrote:
>>>>> When running as guest, under certain condition, it will oops as following.
>>>>> writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
>>>>> is NULL. While other register access won't oops kernel because they use
>>>>> wr32/rd32 which have a defense against NULL pointer.
>>>>> [...]
>>>>
>>>> Incidentally we're just looking for a solution to that problem too.
>>>> Do three patches to fix the same problem at rougly the same time already
>>>> qualify as freak accident?
>>>>
>>>> FTR, I attached my current patch, which I was planning to submit after
>>>> some external testing.
>>>>
>>>> However, all three patches have one thing in common: They workaround
>>>> a somewhat dubious resetting of the hardware address to NULL in case
>>>> reading from a register failed.
>>>>
>>>> That makes me wonder if setting the hardware address to NULL in
>>>> rd32/igb_rd32 is really such a good idea. It's performed in a function
>>>> which return value is *never* tested for validity in the calling
>>>> functions and leads to subsequent crashes since no tests for hw_addr ==
>>>> NULL are performed.
>>>>
>>>> Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
>>>> graceful way to handle the "surprise removal"?
>>>
>>> Answering this from my home account because, well, work is Outlook.
>>>
>>> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
>>> uncertain that the surprise removal code actually works the way I
>>> thought previously and I think I took a lot of it out of my local code.
>>>
>>> Unfortuantely I don't have any equipment that I can use to reproduce
>>> surprise removal any longer so that means I wouldn't be able to test
>>> anything. I have to defer to you or Cao Jin.
>>
>> I'm not too keen to rip out a PCIe NIC under power from my locale
>> desktop machine, but I think an actual surprise removal is not the
>> problem.
>>
>> As described in my git log entry, the error condition in igb_rd32 can be
>> triggered during a suspend. The HW has been put into a sleep state but
>> some register read requests are apparently not guarded against that
>> situation. Reading a register in this state returns -1, thus a suspend
>> is erroneously triggering the "surprise removal" sequence.
>
> The question I would have is what is reading the device when it is in
> this state. The watchdog and any other functions that would read the
> device should be disabled.
>
> One possibility could be a race between a call to igb_close and the
> igb_suspend function. We have seen some of those pop up recently on
> ixgbe and it looks like igb has the same bug. We should probably be
> using the rtnl_lock to guarantee that netif_device_detach and the call
> to __igb_close are completed before igb_close could possibly be called
> by the network stack.
>
>> Here's a raw idea:
>>
>> - Note that device is suspended in e1000_hw struct. Don't trigger
>> error sequence in igb_rd32 if so (...and return a 0 value???)
>
> The thing is that a suspended device should not be accessed at all.
> If we are accessing it while it is suspended then that is a bug. If
> you could throw a WARN_ON call in igb_rd32 to capture where this is
> being triggered that might be useful.
>
>> - Otherwise assume it's actually a surprise removal. In theory that
>> should somehow trigger a device removal sequence, kind of like
>> calling igb_remove, no?
>
> Well a read of the MMIO region while suspended is more of a surprise
> read since there shouldn't be anything going on. We need to isolate
> where that read is coming from and fix it.
>
> Thanks.
>
> - Alex
>
>
> .
>
^ permalink raw reply
* Is Documentation/networking/phy.txt still up-to-date?
From: Sebastian Frias @ 2016-11-09 13:24 UTC (permalink / raw)
To: afleming, jgarzik, Måns Rullgård, Florian Fainelli
Cc: netdev, LKML, David S. Miller
Hi,
Documentation/networking/phy.txt discusses phy_connect and states that:
"...
interface is a u32 which specifies the connection type used
between the controller and the PHY. Examples are GMII, MII,
RGMII, and SGMII. For a full list, see include/linux/phy.h
Now just make sure that phydev->supported and phydev->advertising have any
values pruned from them which don't make sense for your controller (a 10/100
controller may be connected to a gigabit capable PHY, so you would need to
mask off SUPPORTED_1000baseT*). See include/linux/ethtool.h for definitions
for these bitfields. Note that you should not SET any bits, or the PHY may
get put into an unsupported state.
..."
However, 'drivers/net/ethernet/aurora/nb8800.c' for example, does SETs some
bits (in function 'nb8800_pause_adv').
I checked 'drivers/net/ethernet/broadcom/genet/bcmmii.c' and that one CLEARs
bits (as per the documentation).
Does anybody knows what is the correct/recommended approach?
Best regards,
Sebastian
^ permalink raw reply
* [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Caesar Wang @ 2016-11-09 13:21 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Mark Yao, Yakir Yang, Caesar Wang,
Douglas Anderson, David Wu, Jianqun Xu, devicetree, Brian Norris,
linux-kernel, zhangqing, linux-rockchip, Rob Herring, Will Deacon,
Ziyuan Xu, Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Mark Yao <mark.yao@rock-chips.com>
Add the core display-subsystem node and the two display controllers
available on the rk3399.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58 ++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e5b5b3d..f1d289a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1290,6 +1290,64 @@
status = "disabled";
};
+ vopl: vop@ff8f0000 {
+ compatible = "rockchip,rk3399-vop-lit";
+ reg = <0x0 0xff8f0000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopl_mmu>;
+ status = "disabled";
+
+ vopl_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopl_mmu: iommu@ff8f3f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff8f3f00 0x0 0x100>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopl_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ vopb: vop@ff900000 {
+ compatible = "rockchip,rk3399-vop-big";
+ reg = <0x0 0xff900000 0x0 0x3efc>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&vopb_mmu>;
+ status = "disabled";
+
+ vopb_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vopb_mmu: iommu@ff903f00 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff903f00 0x0 0x100>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "vopb_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ display_subsystem: display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <&vopl_out>, <&vopb_out>;
+ status = "disabled";
+ };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <&grf>;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Tomasz Nowicki @ 2016-11-09 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018160414.1228-14-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ea90bc8..04cc5f7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> }
>
[...]
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node =
> + *(struct acpi_iort_node **)dev_get_platdata(dev);
> + struct acpi_iort_smmu *iort_smmu;
> + u64 *glb_irq;
> + int ret;
> +
> + /* Retrieve SMMU1/2 specific data */
> + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> + &smmu->model);
> + if (ret < 0)
> + return ret;
> +
> + glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
> + iort_smmu->global_interrupt_offset);
One bug that I found:
- glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
- iort_smmu->global_interrupt_offset);
+ glb_irq = ACPI_ADD_PTR(u64, node,
+ iort_smmu->global_interrupt_offset);
With this fix, I run VM with several PCI devices (NIC, SATA) in
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki <tn@semihalf.com> for all series.
> +
> + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> + smmu->num_global_irqs = 1;
> + else
> + smmu->num_global_irqs = 2;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
Thanks,
Tomasz
^ permalink raw reply
* Re: [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Tomasz Nowicki @ 2016-11-09 13:24 UTC (permalink / raw)
To: Lorenzo Pieralisi, iommu, Eric Auger
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Marc Zyngier,
Rafael J. Wysocki, Hanjun Guo, Jon Masters, Sinan Kaya,
Nate Watterson, Prem Mallappa, Dennis Chen, linux-acpi, linux-pci,
linux-kernel, linux-arm-kernel
In-Reply-To: <20161018160414.1228-14-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ea90bc8..04cc5f7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> }
>
[...]
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node =
> + *(struct acpi_iort_node **)dev_get_platdata(dev);
> + struct acpi_iort_smmu *iort_smmu;
> + u64 *glb_irq;
> + int ret;
> +
> + /* Retrieve SMMU1/2 specific data */
> + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> + &smmu->model);
> + if (ret < 0)
> + return ret;
> +
> + glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
> + iort_smmu->global_interrupt_offset);
One bug that I found:
- glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
- iort_smmu->global_interrupt_offset);
+ glb_irq = ACPI_ADD_PTR(u64, node,
+ iort_smmu->global_interrupt_offset);
With this fix, I run VM with several PCI devices (NIC, SATA) in
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki <tn@semihalf.com> for all series.
> +
> + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> + smmu->num_global_irqs = 1;
> + else
> + smmu->num_global_irqs = 2;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
Thanks,
Tomasz
^ permalink raw reply
* Re: [PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Tomasz Nowicki @ 2016-11-09 13:24 UTC (permalink / raw)
To: Lorenzo Pieralisi,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Eric Auger
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Marc Zyngier,
Rafael J. Wysocki, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Sinan Kaya,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, Jon Masters, Dennis Chen,
Prem Mallappa
In-Reply-To: <20161018160414.1228-14-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
Hi Lorenzo,
On 18.10.2016 18:04, Lorenzo Pieralisi wrote:
> In ACPI bases systems, in order to be able to create platform
> devices and initialize them for ARM SMMU components, the IORT
> kernel implementation requires a set of static functions to be
> used by the IORT kernel layer to configure platform devices for
> ARM SMMU components.
>
> Add static configuration functions to the IORT kernel layer for
> the ARM SMMU components, so that the ARM SMMU driver can
> initialize its respective platform device by relying on the IORT
> kernel infrastructure and by adding a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
> Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Cc: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Cc: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
> ---
> drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/iommu/arm-smmu.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/acpi_iort.h | 3 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ea90bc8..04cc5f7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> }
>
[...]
> +
> +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct acpi_iort_node *node =
> + *(struct acpi_iort_node **)dev_get_platdata(dev);
> + struct acpi_iort_smmu *iort_smmu;
> + u64 *glb_irq;
> + int ret;
> +
> + /* Retrieve SMMU1/2 specific data */
> + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> +
> + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> + &smmu->model);
> + if (ret < 0)
> + return ret;
> +
> + glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
> + iort_smmu->global_interrupt_offset);
One bug that I found:
- glb_irq = ACPI_ADD_PTR(u64, iort_smmu,
- iort_smmu->global_interrupt_offset);
+ glb_irq = ACPI_ADD_PTR(u64, node,
+ iort_smmu->global_interrupt_offset);
With this fix, I run VM with several PCI devices (NIC, SATA) in
passthrough mode successfully on ACPI host using ThunderX 1-socket board.
Also, for my tests I used Eric's patches:
https://github.com/eauger/linux/commits/v4.9-rc3-reserved-rfc-v2
Including bug fix above:
Tested-by: Tomasz Nowicki <tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org> for all series.
> +
> + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> + smmu->num_global_irqs = 1;
> + else
> + smmu->num_global_irqs = 2;
> +
> + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> +
> + return 0;
> +}
> +#else
> +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> + struct arm_smmu_device *smmu)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v2 8/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Caesar Wang @ 2016-11-09 13:22 UTC (permalink / raw)
To: Heiko Stuebner
Cc: eddie.cai, tfiga, Brian Norris, Caesar Wang, Douglas Anderson,
David Wu, Jianqun Xu, devicetree, linux-kernel, zhangqing,
Shawn Lin, Rob Herring, Will Deacon, linux-rockchip, Mark Rutland,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-1-git-send-email-wxt@rock-chips.com>
From: Brian Norris <briannorris@chromium.org>
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v2:
- the original patches from brian posting on
https://chromium-review.googlesource.com/343603
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54 ++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 09ebf4e..3659c56 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -353,6 +353,60 @@
status = "disabled";
};
+ usbdrd3_0: usb@fe800000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_0: dwc3@fe800000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe800000 0x0 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "otg";
+ phys = <&tcphy0_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
+ usbdrd3_1: usb@fe900000 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
+ <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_1: dwc3@fe900000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe900000 0x0 0x100000>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
+ dr_mode = "host";
+ phys = <&tcphy1_usb3>;
+ phy-names = "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,xhci-slow-suspend-quirk;
+ status = "disabled";
+ };
+ };
+
gic: interrupt-controller@fee00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
--
2.7.4
^ 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.