Re: [PATCH] staging: rtl8192e: Fix possible buffer overflow in _rtl92e_wx_set_scan
On Fri, Mar 05, 2021 at 03:00:14PM +, Lee wrote:
>
> Hi Dan,
>
> Do you think any of these could be potential issues:
>
> driver/staging/
>
> rtl8192e/rtllib_rx.c:2442
memcpy(dst->ssid, src->ssid, src->ssid_len);
Smatch says that at this point we know "src->ssid_len" is in the 1-32
range. This is without any fixes to how Smatch parses nl_len().
> wlan-ng/cfg80211.c:316
313 if (request->n_ssids > 0) {
314 msg1.scantype.data = P80211ENUM_scantype_active;
315 msg1.ssid.data.len = request->ssids->ssid_len;
316 memcpy(msg1.ssid.data.data,
317 request->ssids->ssid, request->ssids->ssid_len);
318 } else {
The only thing Smatch knows about "request->ssids->ssid_len" is that
it's 0-255. I had not marked "msg1.ssid.data.data" as a protected
struct member so it didn't generate a warning.
I think cfg80211_scan_request structs are filled out in a systematic
way in ieee80211_request_ibss_scan() and they're bounds checked properly
so this isn't a bug.
> rtl8723bs/os_dep/ioctl_cfg80211.c:1591
> rtl8723bs/os_dep/ioctl_cfg80211.c:2738
Same.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Saluti!
Buona giornata, C'è una questione urgente, che si riferisce al trasferimento di una grande quantità di denaro su un conto all'estero, con il tuo aiuto come partner straniero come beneficiario dei fondi. Se sei interessato, rispondi tramite la mia email privata qui sotto. E-mail: director.zh...@zhengfuqing.com I migliori saluti, Direttore esecutivo. ICBC. --- Avast 防毒軟體已檢查此封電子郵件的病毒。 https://www.avast.com/antivirus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wimax: i2400m: fix some incorrect type warnings
Fix some "incorrect type in assignment" warnings reported by sparse in fw.c sparse warnings: wimax/i2400m/fw.c:266:27: warning: cast to restricted __le32 wimax/i2400m/fw.c:266:25: warning: incorrect type in assignment (different base types) wimax/i2400m/fw.c:267:27: warning: cast to restricted __le32 wimax/i2400m/fw.c:267:25: warning: incorrect type in assignment (different base types) wimax/i2400m/fw.c:268:27: warning: cast to restricted __le32 wimax/i2400m/fw.c:268:25: warning: incorrect type in assignment (different base types) wimax/i2400m/fw.c:269:27: warning: cast to restricted __le32 wimax/i2400m/fw.c:269:25: warning: incorrect type in assignment (different base types) Signed-off-by: Darryl T. Agostinelli --- drivers/staging/wimax/i2400m/fw.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/wimax/i2400m/fw.c b/drivers/staging/wimax/i2400m/fw.c index 92ea5c101e76..f0e43dbd02f6 100644 --- a/drivers/staging/wimax/i2400m/fw.c +++ b/drivers/staging/wimax/i2400m/fw.c @@ -263,10 +263,10 @@ int i2400m_barker_db_add(u32 barker_id) return result; } barker = i2400m_barker_db + i2400m_barker_db_used++; - barker->data[0] = le32_to_cpu(barker_id); - barker->data[1] = le32_to_cpu(barker_id); - barker->data[2] = le32_to_cpu(barker_id); - barker->data[3] = le32_to_cpu(barker_id); + barker->data[0] = cpu_to_le32(barker_id); + barker->data[1] = cpu_to_le32(barker_id); + barker->data[2] = cpu_to_le32(barker_id); + barker->data[3] = cpu_to_le32(barker_id); return 0; } -- 2.29.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/10] spi: finalize 'delay_usecs' removal/transition
A while back I started the introduction of the 'spi_delay' data type: https://lore.kernel.org/linux-spi/20190926105147.7839-1-alexandru.ardel...@analog.com/ Users of the 'delay_usecs' were removed from drivers. Now it's time to remove the 'delay_usecs' from the SPI subsystem and use only the 'delay' field. This changeset adapts all SPI drivers to do without 'delay_usecs'. Additionally, for greybus we need to adapt it to use the 'delay' in nano-seconds and convert it to micro-seconds. Alexandru Ardelean (10): spi: spi-axi-spi-engine: remove usage of delay_usecs spi: bcm63xx-spi: don't check 'delay_usecs' field spi: spi-bcm-qspi: replace 'delay_usecs' with 'delay.value' check spi: spi-sh: replace 'delay_usecs' with 'delay.value' in pr_debug spi: spi-tegra20-flash: don't check 'delay_usecs' field for spi transfer staging: greybus: spilib: use 'spi_delay_to_ns' for getting xfer delay spi: spi-falcon: remove check for 'delay_usecs' spi: fsl-espi: remove usage of 'delay_usecs' field spi: core: remove 'delay_usecs' field from spi_transfer spi: docs: update info about 'delay_usecs' Documentation/spi/spi-summary.rst | 7 +-- drivers/spi/spi-axi-spi-engine.c | 12 drivers/spi/spi-bcm-qspi.c| 2 +- drivers/spi/spi-bcm63xx.c | 2 +- drivers/spi/spi-falcon.c | 2 +- drivers/spi/spi-fsl-espi.c| 17 + drivers/spi/spi-sh.c | 4 ++-- drivers/spi/spi-tegra20-sflash.c | 3 +-- drivers/spi/spi.c | 1 - drivers/staging/greybus/spilib.c | 5 - include/linux/spi/spi.h | 12 11 files changed, 24 insertions(+), 43 deletions(-) -- 2.29.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 01/10] spi: spi-axi-spi-engine: remove usage of delay_usecs
The 'delay_usecs' field was handled for backwards compatibility in case
there were some users that still configured SPI delay transfers with
this field.
They should all be removed by now.
Signed-off-by: Alexandru Ardelean
---
drivers/spi/spi-axi-spi-engine.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-axi-spi-engine.c b/drivers/spi/spi-axi-spi-engine.c
index af86e6d6e16b..80c3e38f5c1b 100644
--- a/drivers/spi/spi-axi-spi-engine.c
+++ b/drivers/spi/spi-axi-spi-engine.c
@@ -170,14 +170,10 @@ static void spi_engine_gen_sleep(struct
spi_engine_program *p, bool dry,
unsigned int t;
int delay;
- if (xfer->delay_usecs) {
- delay = xfer->delay_usecs;
- } else {
- delay = spi_delay_to_ns(&xfer->delay, xfer);
- if (delay < 0)
- return;
- delay /= 1000;
- }
+ delay = spi_delay_to_ns(&xfer->delay, xfer);
+ if (delay < 0)
+ return;
+ delay /= 1000;
if (delay == 0)
return;
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 02/10] spi: bcm63xx-spi: don't check 'delay_usecs' field
The 'delay_usecs' field was handled for backwards compatibility in case
there were some users that still configured SPI delay transfers with
this field.
They should all be removed by now.
Signed-off-by: Alexandru Ardelean
---
drivers/spi/spi-bcm63xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-bcm63xx.c b/drivers/spi/spi-bcm63xx.c
index d08bb7600150..80fa0ef8909c 100644
--- a/drivers/spi/spi-bcm63xx.c
+++ b/drivers/spi/spi-bcm63xx.c
@@ -369,7 +369,7 @@ static int bcm63xx_spi_transfer_one(struct spi_master
*master,
}
/* CS will be deasserted directly after transfer */
- if (t->delay_usecs || t->delay.value) {
+ if (t->delay.value) {
dev_err(&spi->dev, "unable to keep CS asserted after
transfer\n");
status = -EINVAL;
goto exit;
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/10] spi: spi-bcm-qspi: replace 'delay_usecs' with 'delay.value' check
The 'delay_usecs' field is going away. The replacement for it is the
'delay' field. So, we should check for 'delay.value' being non-zero.
Signed-off-by: Alexandru Ardelean
---
drivers/spi/spi-bcm-qspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-bcm-qspi.c b/drivers/spi/spi-bcm-qspi.c
index 707fe3a5d8ef..a78e56f566dd 100644
--- a/drivers/spi/spi-bcm-qspi.c
+++ b/drivers/spi/spi-bcm-qspi.c
@@ -671,7 +671,7 @@ static int update_qspi_trans_byte_count(struct bcm_qspi
*qspi,
if (qt->byte >= qt->trans->len) {
/* we're at the end of the spi_transfer */
/* in TX mode, need to pause for a delay or CS change */
- if (qt->trans->delay_usecs &&
+ if (qt->trans->delay.value &&
(flags & TRANS_STATUS_BREAK_DELAY))
ret |= TRANS_STATUS_BREAK_DELAY;
if (qt->trans->cs_change &&
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 04/10] spi: spi-sh: replace 'delay_usecs' with 'delay.value' in pr_debug
The 'delay_usecs' field is going away. The replacement for it is the
'delay' field. So, we should print the 'delay.value' value instead.
Signed-off-by: Alexandru Ardelean
---
drivers/spi/spi-sh.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-sh.c b/drivers/spi/spi-sh.c
index 15123a8f41e1..45f304935332 100644
--- a/drivers/spi/spi-sh.c
+++ b/drivers/spi/spi-sh.c
@@ -290,8 +290,8 @@ static void spi_sh_work(struct work_struct *work)
list_for_each_entry(t, &mesg->transfers, transfer_list) {
pr_debug("tx_buf = %p, rx_buf = %p\n",
t->tx_buf, t->rx_buf);
- pr_debug("len = %d, delay_usecs = %d\n",
- t->len, t->delay_usecs);
+ pr_debug("len = %d, delay.value = %d\n",
+ t->len, t->delay.value);
if (t->tx_buf) {
ret = spi_sh_send(ss, mesg, t);
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 05/10] spi: spi-tegra20-flash: don't check 'delay_usecs' field for spi transfer
The 'delay_usecs' field was handled for backwards compatibility in case
there were some users that still configured SPI delay transfers with
this field.
They should all be removed by now. So we can remove the 'delay_usecs'
handling in this driver.
Signed-off-by: Alexandru Ardelean
---
drivers/spi/spi-tegra20-sflash.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/spi-tegra20-sflash.c b/drivers/spi/spi-tegra20-sflash.c
index cfb7de737937..2888d8a8dc6d 100644
--- a/drivers/spi/spi-tegra20-sflash.c
+++ b/drivers/spi/spi-tegra20-sflash.c
@@ -341,8 +341,7 @@ static int tegra_sflash_transfer_one_message(struct
spi_master *master,
goto exit;
}
msg->actual_length += xfer->len;
- if (xfer->cs_change &&
- (xfer->delay_usecs || xfer->delay.value)) {
+ if (xfer->cs_change && xfer->delay.value) {
tegra_sflash_writel(tsd, tsd->def_command_reg,
SPI_COMMAND);
spi_transfer_delay_exec(xfer);
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 06/10] staging: greybus: spilib: use 'spi_delay_to_ns' for getting xfer delay
The intent is the removal of the 'delay_usecs' field from the
spi_transfer struct, as there is a 'delay' field that does the same
thing.
The spi_delay_to_ns() can be used to get the transfer delay. It works by
using the 'delay_usecs' field first (if it is non-zero), and finally
uses the 'delay' field.
Since the 'delay_usecs' field is going away, this change makes use of the
spi_delay_to_ns() function. This also means dividing the return value of
the function by 1000, to convert it to microseconds.
To prevent any potential faults when converting to microseconds and since
the result of spi_delay_to_ns() is int, the delay is being computed in 32
bits and then clamped between 0 & U16_MAX.
Signed-off-by: Alexandru Ardelean
---
drivers/staging/greybus/spilib.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/spilib.c b/drivers/staging/greybus/spilib.c
index 672d540d3365..30655153df6a 100644
--- a/drivers/staging/greybus/spilib.c
+++ b/drivers/staging/greybus/spilib.c
@@ -245,6 +245,7 @@ static struct gb_operation *gb_spi_operation_create(struct
gb_spilib *spi,
/* Fill in the transfers array */
xfer = spi->first_xfer;
while (msg->state != GB_SPI_STATE_OP_DONE) {
+ int xfer_delay;
if (xfer == spi->last_xfer)
xfer_len = spi->last_xfer_size;
else
@@ -259,7 +260,9 @@ static struct gb_operation *gb_spi_operation_create(struct
gb_spilib *spi,
gb_xfer->speed_hz = cpu_to_le32(xfer->speed_hz);
gb_xfer->len = cpu_to_le32(xfer_len);
- gb_xfer->delay_usecs = cpu_to_le16(xfer->delay_usecs);
+ xfer_delay = spi_delay_to_ns(&xfer->delay, xfer) / 1000;
+ xfer_delay = clamp_t(u16, xfer_delay, 0, U16_MAX);
+ gb_xfer->delay_usecs = cpu_to_le16(xfer_delay);
gb_xfer->cs_change = xfer->cs_change;
gb_xfer->bits_per_word = xfer->bits_per_word;
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 07/10] spi: spi-falcon: remove check for 'delay_usecs'
The 'delay_usecs' field is being removed from the spi_transfer struct. This change removes it from the SPI Falcon driver. Signed-off-by: Alexandru Ardelean --- drivers/spi/spi-falcon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-falcon.c b/drivers/spi/spi-falcon.c index d3336a63f462..a7d4dffac66b 100644 --- a/drivers/spi/spi-falcon.c +++ b/drivers/spi/spi-falcon.c @@ -377,7 +377,7 @@ static int falcon_sflash_xfer_one(struct spi_master *master, m->actual_length += t->len; - WARN_ON(t->delay_usecs || t->delay.value || t->cs_change); + WARN_ON(t->delay.value || t->cs_change); spi_flags = 0; } -- 2.29.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 08/10] spi: fsl-espi: remove usage of 'delay_usecs' field
The 'delay_usecs' field is being removed from the spi_transfer struct.
This change removes it from the SPI FSL ESPI driver.
Signed-off-by: Alexandru Ardelean
---
drivers/spi/spi-fsl-espi.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index cf2b947c600e..f7066bef7b06 100644
--- a/drivers/spi/spi-fsl-espi.c
+++ b/drivers/spi/spi-fsl-espi.c
@@ -435,8 +435,7 @@ static int fsl_espi_trans(struct spi_message *m, struct
spi_transfer *trans)
static int fsl_espi_do_one_msg(struct spi_master *master,
struct spi_message *m)
{
- unsigned int delay_usecs = 0, rx_nbits = 0;
- unsigned int delay_nsecs = 0, delay_nsecs1 = 0;
+ unsigned int rx_nbits = 0, delay_nsecs = 0;
struct spi_transfer *t, trans = {};
int ret;
@@ -445,16 +444,10 @@ static int fsl_espi_do_one_msg(struct spi_master *master,
goto out;
list_for_each_entry(t, &m->transfers, transfer_list) {
- if (t->delay_usecs) {
- if (t->delay_usecs > delay_usecs) {
- delay_usecs = t->delay_usecs;
- delay_nsecs = delay_usecs * 1000;
- }
- } else {
- delay_nsecs1 = spi_delay_to_ns(&t->delay, t);
- if (delay_nsecs1 > delay_nsecs)
- delay_nsecs = delay_nsecs1;
- }
+ unsigned int delay = spi_delay_to_ns(&t->delay, t);
+
+ if (delay > delay_nsecs)
+ delay_nsecs = delay;
if (t->rx_nbits > rx_nbits)
rx_nbits = t->rx_nbits;
}
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 09/10] spi: core: remove 'delay_usecs' field from spi_transfer
The 'delay' field in the spi_transfer struct is meant to replace the
'delay_usecs' field. However some cleanup was required to remove the
uses of 'delay_usecs'. Now that it's been cleaned up, we can remove it
from the kernel tree.
Signed-off-by: Alexandru Ardelean
---
drivers/spi/spi.c | 1 -
include/linux/spi/spi.h | 12
2 files changed, 13 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index b08efe88ccd6..481427780162 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -3178,7 +3178,6 @@ struct spi_replaced_transfers *spi_replace_transfers(
/* clear cs_change and delay for all but the last */
if (i) {
xfer->cs_change = false;
- xfer->delay_usecs = 0;
xfer->delay.value = 0;
}
}
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 592897fa4f03..ea1784a43267 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -832,9 +832,6 @@ extern void spi_res_release(struct spi_controller *ctlr,
* @delay: delay to be introduced after this transfer before
* (optionally) changing the chipselect status, then starting
* the next transfer or completing this @spi_message.
- * @delay_usecs: microseconds to delay after this transfer before
- * (optionally) changing the chipselect status, then starting
- * the next transfer or completing this @spi_message.
* @word_delay: inter word delay to be introduced after each word size
* (set by bits_per_word) transmission.
* @effective_speed_hz: the effective SCK-speed that was used to
@@ -946,7 +943,6 @@ struct spi_transfer {
#defineSPI_NBITS_DUAL 0x02 /* 2bits transfer */
#defineSPI_NBITS_QUAD 0x04 /* 4bits transfer */
u8 bits_per_word;
- u16 delay_usecs;
struct spi_delaydelay;
struct spi_delaycs_change_delay;
struct spi_delayword_delay;
@@ -1060,14 +1056,6 @@ spi_transfer_del(struct spi_transfer *t)
static inline int
spi_transfer_delay_exec(struct spi_transfer *t)
{
- struct spi_delay d;
-
- if (t->delay_usecs) {
- d.value = t->delay_usecs;
- d.unit = SPI_DELAY_UNIT_USECS;
- return spi_delay_exec(&d, NULL);
- }
-
return spi_delay_exec(&t->delay, t);
}
--
2.29.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 10/10] spi: docs: update info about 'delay_usecs'
The 'delay_usecs' field is no longer present on the spi_transfer struct. This change updates the doc to mention the usage of the (relatively) new 'delay' field. Signed-off-by: Alexandru Ardelean --- Documentation/spi/spi-summary.rst | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-summary.rst index f1daffe10d78..d4239025461d 100644 --- a/Documentation/spi/spi-summary.rst +++ b/Documentation/spi/spi-summary.rst @@ -411,8 +411,11 @@ any more such messages. duplex (one pointer is NULL) transfers; + optionally defining short delays after transfers ... using -the spi_transfer.delay_usecs setting (this delay can be the -only protocol effect, if the buffer length is zero); +the spi_transfer.delay.value setting (this delay can be the +only protocol effect, if the buffer length is zero) ... +when specifying this delay the default spi_transfer.delay.unit +is microseconds, however this can be adjusted to clock cycles +or nanoseconds if needed; + whether the chipselect becomes inactive after a transfer and any delay ... by using the spi_transfer.cs_change flag; -- 2.29.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/10] spi: spi-axi-spi-engine: remove usage of delay_usecs
On 3/8/21 3:54 PM, Alexandru Ardelean wrote:
The 'delay_usecs' field was handled for backwards compatibility in case
there were some users that still configured SPI delay transfers with
this field.
They should all be removed by now.
Signed-off-by: Alexandru Ardelean
---
drivers/spi/spi-axi-spi-engine.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-axi-spi-engine.c b/drivers/spi/spi-axi-spi-engine.c
index af86e6d6e16b..80c3e38f5c1b 100644
--- a/drivers/spi/spi-axi-spi-engine.c
+++ b/drivers/spi/spi-axi-spi-engine.c
@@ -170,14 +170,10 @@ static void spi_engine_gen_sleep(struct
spi_engine_program *p, bool dry,
unsigned int t;
int delay;
- if (xfer->delay_usecs) {
- delay = xfer->delay_usecs;
- } else {
- delay = spi_delay_to_ns(&xfer->delay, xfer);
- if (delay < 0)
- return;
- delay /= 1000;
- }
+ delay = spi_delay_to_ns(&xfer->delay, xfer);
+ if (delay < 0)
+ return;
Bit of a nit, but this could be `delay <= 0` and then drop the check for
`delay == 0` below.
+ delay /= 1000;
if (delay == 0)
return;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/5] Reset driver for IMX8MQ VPU hardware block
On Mon, Mar 01, 2021 at 04:17:49PM +0100, Benjamin Gaignard wrote: > The two VPUs inside IMX8MQ share the same control block which can be see > as a reset hardware block. > In order to be able to add the second VPU (for HECV decoding) it will be > more handy if the both VPU drivers instance don't have to share the > control block registers. This lead to implement it as an independ reset > driver and to change the VPU driver to use it. > > Please note that this series break the compatibility between the DTB and > kernel. This break is limited to IMX8MQ SoC and is done when the driver > is still in staging directory. As this information will be lost, please put in the binding and dts patch. > > version 3: > - Fix error in VPU example node > > version 2: > - Document the change in VPU bindings > > Benjamin Gaignard (5): > dt-bindings: reset: IMX8MQ VPU reset > dt-bindings: media: IMX8MQ VPU: document reset usage > reset: Add reset driver for IMX8MQ VPU block > media: hantro: Use reset driver > arm64: dts: imx8mq: Use reset driver for VPU hardware block > > .../bindings/media/nxp,imx8mq-vpu.yaml| 14 +- > .../bindings/reset/fsl,imx8mq-vpu-reset.yaml | 54 ++ > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++- > drivers/reset/Kconfig | 8 + > drivers/reset/Makefile| 1 + > drivers/reset/reset-imx8mq-vpu.c | 169 ++ > drivers/staging/media/hantro/Kconfig | 1 + > drivers/staging/media/hantro/imx8m_vpu_hw.c | 61 ++- > include/dt-bindings/reset/imx8mq-vpu-reset.h | 16 ++ > 9 files changed, 294 insertions(+), 61 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml > create mode 100644 drivers/reset/reset-imx8mq-vpu.c > create mode 100644 include/dt-bindings/reset/imx8mq-vpu-reset.h > > -- > 2.25.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/5] dt-bindings: reset: IMX8MQ VPU reset
On Mon, Mar 01, 2021 at 04:17:50PM +0100, Benjamin Gaignard wrote:
> Document bindings for IMX8MQ VPU reset hardware block
>
> Signed-off-by: Benjamin Gaignard
> ---
> .../bindings/reset/fsl,imx8mq-vpu-reset.yaml | 54 +++
> include/dt-bindings/reset/imx8mq-vpu-reset.h | 16 ++
> 2 files changed, 70 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml
> create mode 100644 include/dt-bindings/reset/imx8mq-vpu-reset.h
>
> diff --git
> a/Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml
> b/Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml
> new file mode 100644
> index ..00020421c0e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reset/fsl,imx8mq-vpu-reset.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8MQ VPU Reset Controller
> +
> +maintainers:
> + - Benjamin Gaignard
> +
> +description: |
> + The VPU reset controller is used to reset the video processor
> + unit peripherals. Device nodes that need access to reset lines should
> + specify them as a reset phandle in their corresponding node as
> + specified in reset.txt.
> +
> + For list of all valid reset indices see
> + for i.MX8MQ.
> +
> +properties:
> + compatible:
> +items:
> + - const: fsl,imx8mq-vpu-reset
> + - const: syscon
Is there other functionality in the block? If so, add some details in
'description' above.
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +minItems: 1
> +maxItems: 3
Need to say what each clock is.
> +
> + '#reset-cells':
> +const: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - '#reset-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +vpu-reset@3832 {
reset-controller@...
> +compatible = "fsl,imx8mq-vpu-reset", "syscon";
> +reg = <0x3832 0x1>;
> +clocks = <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
> +#reset-cells = <1>;
> +};
> diff --git a/include/dt-bindings/reset/imx8mq-vpu-reset.h
> b/include/dt-bindings/reset/imx8mq-vpu-reset.h
> new file mode 100644
> index ..efcbe18177fe
> --- /dev/null
> +++ b/include/dt-bindings/reset/imx8mq-vpu-reset.h
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2021, Collabora
> + *
> + * i.MX7 System Reset Controller (SRC) driver
> + *
> + * Author: Benjamin Gaignard
> + */
> +
> +#ifndef DT_BINDINGS_VPU_RESET_IMX8MQ
> +#define DT_BINDINGS_VPU_RESET_IMX8MQ
> +
> +#define IMX8MQ_RESET_VPU_RESET_G10
> +#define IMX8MQ_RESET_VPU_RESET_G21
> +
> +#endif
> --
> 2.25.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/5] Reset driver for IMX8MQ VPU hardware block
On Mon, Mar 08, 2021 at 11:22:17AM -0700, Rob Herring wrote: > On Mon, Mar 01, 2021 at 04:17:49PM +0100, Benjamin Gaignard wrote: > > The two VPUs inside IMX8MQ share the same control block which can be see > > as a reset hardware block. > > In order to be able to add the second VPU (for HECV decoding) it will be > > more handy if the both VPU drivers instance don't have to share the > > control block registers. This lead to implement it as an independ reset > > driver and to change the VPU driver to use it. > > > > Please note that this series break the compatibility between the DTB and > > kernel. This break is limited to IMX8MQ SoC and is done when the driver > > is still in staging directory. > > As this information will be lost, please put in the binding and dts > patch. Actually, the adding the VPU reset binding doesn't break compatibility, so just the dts file changes needs it. > > > > > version 3: > > - Fix error in VPU example node > > > > version 2: > > - Document the change in VPU bindings > > > > Benjamin Gaignard (5): > > dt-bindings: reset: IMX8MQ VPU reset > > dt-bindings: media: IMX8MQ VPU: document reset usage > > reset: Add reset driver for IMX8MQ VPU block > > media: hantro: Use reset driver > > arm64: dts: imx8mq: Use reset driver for VPU hardware block > > > > .../bindings/media/nxp,imx8mq-vpu.yaml| 14 +- > > .../bindings/reset/fsl,imx8mq-vpu-reset.yaml | 54 ++ > > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++- > > drivers/reset/Kconfig | 8 + > > drivers/reset/Makefile| 1 + > > drivers/reset/reset-imx8mq-vpu.c | 169 ++ > > drivers/staging/media/hantro/Kconfig | 1 + > > drivers/staging/media/hantro/imx8m_vpu_hw.c | 61 ++- > > include/dt-bindings/reset/imx8mq-vpu-reset.h | 16 ++ > > 9 files changed, 294 insertions(+), 61 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/reset/fsl,imx8mq-vpu-reset.yaml > > create mode 100644 drivers/reset/reset-imx8mq-vpu.c > > create mode 100644 include/dt-bindings/reset/imx8mq-vpu-reset.h > > > > -- > > 2.25.1 > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/5] dt-bindings: media: IMX8MQ VPU: document reset usage
On Mon, 01 Mar 2021 16:17:51 +0100, Benjamin Gaignard wrote: > Document IMX8MQ VPU bindings to add the phandle to the reset driver. > > Provide an independent reset driver allow to the both VPUs to share > their control/reset hardware block. The reset driver replace what > was previously done be using the 'ctrl' registers inside the driver. > > This breaks the compatibility between DTB and kernel but the driver > is still in staging directory and limited to IMX8MQ SoC. > > Signed-off-by: Benjamin Gaignard > --- > version 3: > - Fix error in VPU example node > > .../devicetree/bindings/media/nxp,imx8mq-vpu.yaml | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 2/6] dt: bindings: add mt7621-sysc device tree binding documentation
On Sun, 07 Mar 2021 08:04:22 +0100, Sergio Paracuellos wrote: > Adds device tree binding documentation for clocks in the > MT7621 SOC. > > Signed-off-by: Sergio Paracuellos > --- > .../bindings/clock/mediatek,mt7621-sysc.yaml | 68 +++ > 1 file changed, 68 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/10] staging: greybus: spilib: use 'spi_delay_to_ns' for getting xfer delay
On 08-03-21, 16:54, Alexandru Ardelean wrote:
> The intent is the removal of the 'delay_usecs' field from the
> spi_transfer struct, as there is a 'delay' field that does the same
> thing.
>
> The spi_delay_to_ns() can be used to get the transfer delay. It works by
> using the 'delay_usecs' field first (if it is non-zero), and finally
> uses the 'delay' field.
>
> Since the 'delay_usecs' field is going away, this change makes use of the
> spi_delay_to_ns() function. This also means dividing the return value of
> the function by 1000, to convert it to microseconds.
> To prevent any potential faults when converting to microseconds and since
> the result of spi_delay_to_ns() is int, the delay is being computed in 32
> bits and then clamped between 0 & U16_MAX.
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/staging/greybus/spilib.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/spilib.c
> b/drivers/staging/greybus/spilib.c
> index 672d540d3365..30655153df6a 100644
> --- a/drivers/staging/greybus/spilib.c
> +++ b/drivers/staging/greybus/spilib.c
> @@ -245,6 +245,7 @@ static struct gb_operation
> *gb_spi_operation_create(struct gb_spilib *spi,
> /* Fill in the transfers array */
> xfer = spi->first_xfer;
> while (msg->state != GB_SPI_STATE_OP_DONE) {
> + int xfer_delay;
> if (xfer == spi->last_xfer)
> xfer_len = spi->last_xfer_size;
> else
> @@ -259,7 +260,9 @@ static struct gb_operation
> *gb_spi_operation_create(struct gb_spilib *spi,
>
> gb_xfer->speed_hz = cpu_to_le32(xfer->speed_hz);
> gb_xfer->len = cpu_to_le32(xfer_len);
> - gb_xfer->delay_usecs = cpu_to_le16(xfer->delay_usecs);
> + xfer_delay = spi_delay_to_ns(&xfer->delay, xfer) / 1000;
> + xfer_delay = clamp_t(u16, xfer_delay, 0, U16_MAX);
> + gb_xfer->delay_usecs = cpu_to_le16(xfer_delay);
> gb_xfer->cs_change = xfer->cs_change;
> gb_xfer->bits_per_word = xfer->bits_per_word;
Acked-by: Viresh Kumar
--
viresh
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v11 0/6] MIPS: ralink: add CPU clock detection and clock driver for MT7621
This patchset ports CPU clock detection for MT7621 from OpenWrt and adds a complete clock plan for the mt7621 SOC. The documentation for this SOC only talks about two registers regarding to the clocks: * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for all or some ip cores. Registers needed for this driver to work are in two already mapped areas in its platform's device tree. These are 'sysc' and 'memc' nodes. Most of other drivers just make use of platform operations defined in 'asm/mach-ralink/ralink_regs.h' but this can be avoided declaring this two nodes to be accesible through syscon. Main registers for the clocks are in the sysc control node so this node is merged with clock properties and will also be the clock provider for the SoC. No documentation about a probably existent set of dividers for each ip core is included in the datasheets. So we cannot make anything better, AFAICT. Looking into driver code, and some openWRT patched there are another frequences which are used in some drivers (uart, sd...). According to all of this information the clock plan for this SoC is set as follows: - Main top clock "xtal" from where all the rest of the world is derived. - CPU clock "cpu" derived from "xtal" frequencies and a bunch of register reads and predividers. - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz. - Fixed clocks from "xtal": * "50m": 50 MHz. * "125m": 125 MHz. * "150m": 150 MHz. * "250m": 250 MHz. * "270m": 270 MHz. We also have a buch of gate clocks with their parents: - "hsdma": "150m" - "fe": "250m" - "sp_divtx": "270m" - "timer": "50m" - "pcm": "270m" - "pio": "50m" - "gdma": "bus" - "nand": "125m" - "i2c": "50m" - "i2s": "270m" - "spi": "bus" - "uart1": "50m" - "uart2": "50m" - "uart3": "50m" - "eth": "50m" - "pcie0": "125m" - "pcie1": "125m" - "pcie2": "125m" - "crypto": "250m" - "shxc": "50m" There was a previous attempt of doing this here[0] but the author (Chuanhong Guo) did not wanted to make assumptions of a clock plan for the platform that time. It seems that now he has a better idea of how the clocks are dispossed for this SoC so he share code[1] where some frequencies and clock parents for the gates are coded from a real mediatek private clock plan. I do really want this to be upstreamed so according to the comments in previous attempt[0] from Oleksij Rempel and the frequencies in code[1] I have tried to do this by myself. All of this patches have been tested in a GNUBee PC1 resulting in a working platform. Changes in v11: - Collect Rob's Reviewed-by in bindings documentation patch. - Fix MAINTAINERS patch using file 'mediatek,mt7621-sysc.yaml' for documentation bindings. Changes in v10: - Merge clock properties into 'sysc' system control node making this node a clock provider. - Update driver to use 'mediatek,mt7621-sysc' as compatible string. - Update documentation bindings and its related filename to 'mediatek,mt7621-sysc.yaml'. - Make use of 'linux/bitfields.h' header to avoid some preprocesor shift definitions and just use bit masks decreasing a bit LOC. Changes in v9: - Set two missing ret values to its related PTR_ERR in function 'mt7621_clk_probe' (also related with [3]). - Select MFC_SYSCON in Kconfig. Changes in v8: - Fix kernel test robot complain about the use of 'ret' variable initialized: see [3] Changes in v7: - Make use of CLK_OF_DECLARE_DRIVER instead of CLK_OF_DECLARE and register there only the top clocks that are needed in 'of_clk_init'. The rest of the clocks (fixed and gates) are now registered using a platform driver. Because we have avoid architecture dependent stuff now this has sense because we can enable this driver for COMPILE_TEST. - Convert fixed clocks and gates related function to receive a 'struct device' pointer instead of 'struct device_node' one. - Make use of dev_ APIS in stuff related with platform driver instead of use device_node related stuff. - Add new static global 'mt7621_clk_early' to store pointers to clk_hw registered at 'of_clk_init' stage. Make use of this in platform device probe function to properly copy this into the new required 'clk_data' to provide a properly hierarchy clock structure. - Rename 'mt7621_register_top_clocks' function into a more accurate name now which is 'mt7621_register_early_clocks'. - Enable driver for COMPILE_TEST. Changes in v6: - Rewrite bindings to properly access the registers needed for the driver making use of syscon for two different areas: 'sysc' and 'memc'. With this changes architecture dependent include 'asm/mach-ralink/ralink_regs.h' is not needed anymore because we access this two syscons using a phandle through kernel's regmap APIs. Explan
[PATCH v11 1/6] dt-bindings: clock: add dt binding header for mt7621 clocks
Adds dt binding header for 'mediatek,mt7621-clk' clocks. Acked-by: Rob Herring Signed-off-by: Sergio Paracuellos --- include/dt-bindings/clock/mt7621-clk.h | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 include/dt-bindings/clock/mt7621-clk.h diff --git a/include/dt-bindings/clock/mt7621-clk.h b/include/dt-bindings/clock/mt7621-clk.h new file mode 100644 index ..1422badcf9de --- /dev/null +++ b/include/dt-bindings/clock/mt7621-clk.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Author: Sergio Paracuellos + */ + +#ifndef _DT_BINDINGS_CLK_MT7621_H +#define _DT_BINDINGS_CLK_MT7621_H + +#define MT7621_CLK_XTAL0 +#define MT7621_CLK_CPU 1 +#define MT7621_CLK_BUS 2 +#define MT7621_CLK_50M 3 +#define MT7621_CLK_125M4 +#define MT7621_CLK_150M5 +#define MT7621_CLK_250M6 +#define MT7621_CLK_270M7 + +#define MT7621_CLK_HSDMA 8 +#define MT7621_CLK_FE 9 +#define MT7621_CLK_SP_DIVTX10 +#define MT7621_CLK_TIMER 11 +#define MT7621_CLK_PCM 12 +#define MT7621_CLK_PIO 13 +#define MT7621_CLK_GDMA14 +#define MT7621_CLK_NAND15 +#define MT7621_CLK_I2C 16 +#define MT7621_CLK_I2S 17 +#define MT7621_CLK_SPI 18 +#define MT7621_CLK_UART1 19 +#define MT7621_CLK_UART2 20 +#define MT7621_CLK_UART3 21 +#define MT7621_CLK_ETH 22 +#define MT7621_CLK_PCIE0 23 +#define MT7621_CLK_PCIE1 24 +#define MT7621_CLK_PCIE2 25 +#define MT7621_CLK_CRYPTO 26 +#define MT7621_CLK_SHXC27 + +#define MT7621_CLK_MAX 28 + +#endif /* _DT_BINDINGS_CLK_MT7621_H */ -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v11 2/6] dt: bindings: add mt7621-sysc device tree binding documentation
Adds device tree binding documentation for clocks in the
MT7621 SOC.
Reviewed-by: Rob Herring
Signed-off-by: Sergio Paracuellos
---
.../bindings/clock/mediatek,mt7621-sysc.yaml | 68 +++
1 file changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
new file mode 100644
index ..915f84efd763
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7621-sysc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT7621 Clock Device Tree Bindings
+
+maintainers:
+ - Sergio Paracuellos
+
+description: |
+ The MT7621 has a PLL controller from where the cpu clock is provided
+ as well as derived clocks for the bus and the peripherals. It also
+ can gate SoC device clocks.
+
+ Each clock is assigned an identifier and client nodes use this identifier
+ to specify the clock which they consume.
+
+ All these identifiers could be found in:
+ [1]: .
+
+ The clocks are provided inside a system controller node.
+
+properties:
+ compatible:
+items:
+ - const: mediatek,mt7621-sysc
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+ "#clock-cells":
+description:
+ The first cell indicates the clock number, see [1] for available
+ clocks.
+const: 1
+
+ ralink,memctl:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle of syscon used to control memory registers
+
+ clock-output-names:
+maxItems: 8
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - ralink,memctl
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+sysc: sysc@0 {
+ compatible = "mediatek,mt7621-sysc", "syscon";
+ reg = <0x0 0x100>;
+ #clock-cells = <1>;
+ ralink,memctl = <&memc>;
+ clock-output-names = "xtal", "cpu", "bus",
+ "50m", "125m", "150m",
+ "250m", "270m";
+};
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v11 3/6] clk: ralink: add clock driver for mt7621 SoC
The documentation for this SOC only talks about two
registers regarding to the clocks:
* SYSC_REG_CPLL_CLKCFG0 - provides some information about
boostrapped refclock. PLL and dividers used for CPU and some
sort of BUS.
* SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable
clocks for all or some ip cores.
Looking into driver code, and some openWRT patched there are
another frequencies which are used in some drivers (uart, sd...).
According to all of this information the clock plan for this
SoC is set as follows:
- Main top clock "xtal" from where all the rest of the world is
derived.
- CPU clock "cpu" derived from "xtal" frequencies and a bunch of
register reads and predividers.
- BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz.
- Fixed clocks from "xtal":
* "50m": 50 MHz.
* "125m": 125 MHz.
* "150m": 150 MHz.
* "250m": 250 MHz.
* "270m": 270 MHz.
We also have a buch of gate clocks with their parents:
* "hsdma": "150m"
* "fe": "250m"
* "sp_divtx": "270m"
* "timer": "50m"
* "pcm": "270m"
* "pio": "50m"
* "gdma": "bus"
* "nand": "125m"
* "i2c": "50m"
* "i2s": "270m"
* "spi": "bus"
* "uart1": "50m"
* "uart2": "50m"
* "uart3": "50m"
* "eth": "50m"
* "pcie0": "125m"
* "pcie1": "125m"
* "pcie2": "125m"
* "crypto": "250m"
* "shxc": "50m"
With this information the clk driver will provide clock and gates
functionality from a a set of hardcoded clocks allowing to define
a nice device tree without fixed clocks.
Signed-off-by: Sergio Paracuellos
---
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile| 1 +
drivers/clk/ralink/Kconfig | 15 +
drivers/clk/ralink/Makefile | 2 +
drivers/clk/ralink/clk-mt7621.c | 528
5 files changed, 547 insertions(+)
create mode 100644 drivers/clk/ralink/Kconfig
create mode 100644 drivers/clk/ralink/Makefile
create mode 100644 drivers/clk/ralink/clk-mt7621.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 7c5dc348c16f..70b23da997bf 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -382,6 +382,7 @@ source "drivers/clk/mediatek/Kconfig"
source "drivers/clk/meson/Kconfig"
source "drivers/clk/mvebu/Kconfig"
source "drivers/clk/qcom/Kconfig"
+source "drivers/clk/ralink/Kconfig"
source "drivers/clk/renesas/Kconfig"
source "drivers/clk/rockchip/Kconfig"
source "drivers/clk/samsung/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 5325847469e9..1b35ad852721 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_COMMON_CLK_NXP) += nxp/
obj-$(CONFIG_MACH_PISTACHIO) += pistachio/
obj-$(CONFIG_COMMON_CLK_PXA) += pxa/
obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
+obj-y += ralink/
obj-y += renesas/
obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/
diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig
new file mode 100644
index ..3e3f5cb9ad88
--- /dev/null
+++ b/drivers/clk/ralink/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# MediaTek Mt7621 Clock Driver
+#
+menu "Clock driver for Mediatek mt7621 SoC"
+ depends on SOC_MT7621 || COMPILE_TEST
+
+config CLK_MT7621
+ bool "Clock driver for MediaTek MT7621"
+ depends on SOC_MT7621 || COMPILE_TEST
+ default SOC_MT7621
+ select MFD_SYSCON
+ help
+ This driver supports MediaTek MT7621 basic clocks.
+endmenu
diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile
new file mode 100644
index ..cf6f9216379d
--- /dev/null
+++ b/drivers/clk/ralink/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o
diff --git a/drivers/clk/ralink/clk-mt7621.c b/drivers/clk/ralink/clk-mt7621.c
new file mode 100644
index ..6aea5accd51c
--- /dev/null
+++ b/drivers/clk/ralink/clk-mt7621.c
@@ -0,0 +1,528 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mediatek MT7621 Clock Driver
+ * Author: Sergio Paracuellos
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Configuration registers */
+#define SYSC_REG_SYSTEM_CONFIG0 0x10
+#define SYSC_REG_SYSTEM_CONFIG1 0x14
+#define SYSC_REG_CLKCFG0 0x2c
+#define SYSC_REG_CLKCFG1 0x30
+#define SYSC_REG_CUR_CLK_STS 0x44
+#define MEMC_REG_CPU_PLL 0x648
+
+#define XTAL_MODE_SEL_MASK GENMASK(8, 6)
+#define CPU_CLK_SEL_MASK GENMASK(31, 30)
+#define CUR_CPU_FDIV_MASK GENMASK(12, 8)
+#define CUR_CPU_FFRAC_MASK GENMASK(4, 0)
+#define CPU_PLL_PREDIV_MASKGENMASK(13, 12)
+#define CPU_PLL_FBDIV_MASK GENMASK(10, 4)
+
+struct mt7621_clk_priv {
+ struct regmap *sysc;
+ struc
[PATCH v11 4/6] staging: mt7621-dts: make use of new 'mt7621-clk'
Clocks for SoC mt7621 have been properly integrated so there is
no need to declare fixed clocks at all in the device tree. Remove
all of them, add new device tree nodes for mt7621-clk and update
the rest of the nodes to use them.
Acked-by: Greg Kroah-Hartman
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/gbpc1.dts | 11
drivers/staging/mt7621-dts/mt7621.dtsi | 74 --
2 files changed, 33 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index a7c0d3115d72..7716d0efe524 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -100,17 +100,6 @@ partition@5 {
};
};
-&sysclock {
- compatible = "fixed-clock";
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22500>;
-};
-
-&cpuclock {
- compatible = "fixed-clock";
- clock-frequency = <9>;
-};
-
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 16fc94f65486..b68183e7e6ad 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,5 +1,6 @@
#include
#include
+#include
/ {
#address-cells = <1>;
@@ -27,27 +28,6 @@ aliases {
serial0 = &uartlite;
};
- cpuclock: cpuclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* FIXME: there should be way to detect this */
- clock-frequency = <88000>;
- };
-
- sysclock: sysclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22000>;
- };
-
- mmc_clock: mmc_clock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <4800>;
- };
mmc_fixed_3v3: fixedregulator@0 {
compatible = "regulator-fixed";
@@ -76,8 +56,13 @@ palmbus: palmbus@1E00 {
#size-cells = <1>;
sysc: sysc@0 {
- compatible = "mtk,mt7621-sysc";
+ compatible = "mtk,mt7621-sysc", "syscon";
reg = <0x0 0x100>;
+ #clock-cells = <1>;
+ ralink,memctl = <&memc>;
+ clock-output-names = "xtal", "cpu", "bus",
+"50m", "125m", "150m",
+"250m", "270m";
};
wdt: wdt@100 {
@@ -101,8 +86,8 @@ i2c: i2c@900 {
compatible = "mediatek,mt7621-i2c";
reg = <0x900 0x100>;
- clocks = <&sysclock>;
-
+ clocks = <&sysc MT7621_CLK_I2C>;
+ clock-names = "i2c";
resets = <&rstctrl 16>;
reset-names = "i2c";
@@ -119,8 +104,8 @@ i2s: i2s@a00 {
compatible = "mediatek,mt7621-i2s";
reg = <0xa00 0x100>;
- clocks = <&sysclock>;
-
+ clocks = <&sysc MT7621_CLK_I2S>;
+ clock-names = "i2s";
resets = <&rstctrl 17>;
reset-names = "i2s";
@@ -138,7 +123,7 @@ i2s: i2s@a00 {
};
memc: memc@5000 {
- compatible = "mtk,mt7621-memc";
+ compatible = "mtk,mt7621-memc", "syscon";
reg = <0x5000 0x1000>;
};
@@ -156,8 +141,8 @@ uartlite: uartlite@c00 {
compatible = "ns16550a";
reg = <0xc00 0x100>;
- clocks = <&sysclock>;
- clock-frequency = <5000>;
+ clocks = <&sysc MT7621_CLK_UART1>;
+ clock-names = "uart1";
interrupt-parent = <&gic>;
interrupts = ;
@@ -173,7 +158,8 @@ spi0: spi@b00 {
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
- clocks = <&sysclock>;
+ clocks = <&sysc MT7621_CLK_SPI>;
+ clock-names = "spi";
resets = <&rstctrl 18>;
reset-names = "spi";
@@ -189,6 +175,8 @@ gdma: gdma@2800 {
compatible = "ralink,rt3883-gdma";
reg = <0x2800 0x800>;
+ clocks = <&sysc MT7621_CLK_GDMA>;
+ clock-names = "gdma
[PATCH v11 5/6] staging: mt7621-dts: use valid vendor 'mediatek' instead of invalid 'mtk'
Vendor listed for mediatek in kernel vendor file 'vendor-prefixes.yaml'
contains 'mediatek' as a valid vendor string. Some nodes in the device
tree are using an invalid vendor string vfor 'mtk' instead. Fix all of
them in dts file. Update also ralink mt7621 related code to properly
match new strings. Even there are used in the device tree there are
some strings that are not referred anywhere but have been also updated
with new vendor name. These are 'mtk,mt7621-wdt', 'mtk,mt7621-nand',
'mtk,mt7621-mc', and 'mtk,mt7621-cpc'.
Acked-by: Greg Kroah-Hartman
Signed-off-by: Sergio Paracuellos
---
arch/mips/ralink/mt7621.c | 6 +++---
drivers/staging/mt7621-dts/mt7621.dtsi | 12 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index ca0ac607b0f3..5d74fc1c96ac 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -112,8 +112,8 @@ phys_addr_t mips_cpc_default_phys_base(void)
void __init ralink_of_remap(void)
{
- rt_sysc_membase = plat_of_remap_node("mtk,mt7621-sysc");
- rt_memc_membase = plat_of_remap_node("mtk,mt7621-memc");
+ rt_sysc_membase = plat_of_remap_node("mediatek,mt7621-sysc");
+ rt_memc_membase = plat_of_remap_node("mediatek,mt7621-memc");
if (!rt_sysc_membase || !rt_memc_membase)
panic("Failed to remap core resources");
@@ -181,7 +181,7 @@ void prom_soc_init(struct ralink_soc_info *soc_info)
if (n0 == MT7621_CHIP_NAME0 && n1 == MT7621_CHIP_NAME1) {
name = "MT7621";
- soc_info->compatible = "mtk,mt7621-soc";
+ soc_info->compatible = "mediatek,mt7621-soc";
} else {
panic("mt7621: unknown SoC, n0:%08x n1:%08x\n", n0, n1);
}
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index b68183e7e6ad..f0c9ae757bcd 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -56,7 +56,7 @@ palmbus: palmbus@1E00 {
#size-cells = <1>;
sysc: sysc@0 {
- compatible = "mtk,mt7621-sysc", "syscon";
+ compatible = "mediatek,mt7621-sysc", "syscon";
reg = <0x0 0x100>;
#clock-cells = <1>;
ralink,memctl = <&memc>;
@@ -66,7 +66,7 @@ sysc: sysc@0 {
};
wdt: wdt@100 {
- compatible = "mtk,mt7621-wdt";
+ compatible = "mediatek,mt7621-wdt";
reg = <0x100 0x100>;
};
@@ -123,17 +123,17 @@ i2s: i2s@a00 {
};
memc: memc@5000 {
- compatible = "mtk,mt7621-memc", "syscon";
+ compatible = "mediatek,mt7621-memc", "syscon";
reg = <0x5000 0x1000>;
};
cpc: cpc@1fbf {
-compatible = "mtk,mt7621-cpc";
+compatible = "mediatek,mt7621-cpc";
reg = <0x1fbf 0x8000>;
};
mc: mc@1fbf8000 {
- compatible = "mtk,mt7621-mc";
+ compatible = "mediatek,mt7621-mc";
reg = <0x1fbf8000 0x8000>;
};
@@ -361,7 +361,7 @@ timer {
nand: nand@1e003000 {
status = "disabled";
- compatible = "mtk,mt7621-nand";
+ compatible = "mediatek,mt7621-nand";
bank-width = <2>;
reg = <0x1e003000 0x800
0x1e003800 0x800>;
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v11 6/6] MAINTAINERS: add MT7621 CLOCK maintainer
Adding myself as maintainer for mt7621 clock driver. Signed-off-by: Sergio Paracuellos --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 809a68af5efd..ecad5d972122 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11288,6 +11288,12 @@ L: linux-wirel...@vger.kernel.org S: Maintained F: drivers/net/wireless/mediatek/mt7601u/ +MEDIATEK MT7621 CLOCK DRIVER +M: Sergio Paracuellos +S: Maintained +F: Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml +F: drivers/clk/ralink/clk-mt7621.c + MEDIATEK MT7621/28/88 I2C DRIVER M: Stefan Roese L: linux-...@vger.kernel.org -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
