Re: [PATCH] sysctl: Make sure proc handlers can't expose heap memory
On Mon, May 04, 2020 at 12:08:55PM -0700, Kees Cook wrote: > Just as a precaution, make sure that proc handlers don't accidentally > grow "count" beyond the allocated kbuf size. > > Signed-off-by: Kees Cook > --- > This applies to hch's sysctl cleanup tree... This looks ok o me. You should probably add Al to the Cc list as he has picked up my series into a branch of vfs.git. Acked-by: Christoph Hellwig
Re: [PATCH 5/5] sysctl: pass kernel pointers to ->proc_handler
On Mon, May 04, 2020 at 12:01:11PM -0700, Kees Cook wrote: > > if (error) > > - goto out; > > + goto out_free_buf; > > > > /* careful: calling conventions are nasty here */ > > Is this comment still valid after doing these cleanups? The comment is pretty old so I decided to keep it. That being said I'm not sure it really is very helpful.
Re: [PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
On 04.05.2020 13:53, Daniel Vetter wrote:
> On Fri, May 01, 2020 at 05:49:33PM +0200, Michał Orzeł wrote:
>>
>>
>> On 30.04.2020 20:30, Daniel Vetter wrote:
>>> On Thu, Apr 30, 2020 at 5:38 PM Sean Paul wrote:
On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula
wrote:
>
> On Tue, 28 Apr 2020, Michal Orzel wrote:
>> As suggested by the TODO list for the kernel DRM subsystem, replace
>> the deprecated functions that take/drop modeset locks with new helpers.
>>
>> Signed-off-by: Michal Orzel
>> ---
>> drivers/gpu/drm/drm_mode_object.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mode_object.c
>> b/drivers/gpu/drm/drm_mode_object.c
>> index 35c2719..901b078 100644
>> --- a/drivers/gpu/drm/drm_mode_object.c
>> +++ b/drivers/gpu/drm/drm_mode_object.c
>> @@ -402,12 +402,13 @@ int drm_mode_obj_get_properties_ioctl(struct
>> drm_device *dev, void *data,
>> {
>> struct drm_mode_obj_get_properties *arg = data;
>> struct drm_mode_object *obj;
>> + struct drm_modeset_acquire_ctx ctx;
>> int ret = 0;
>>
>> if (!drm_core_check_feature(dev, DRIVER_MODESET))
>> return -EOPNOTSUPP;
>>
>> - drm_modeset_lock_all(dev);
>> + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>
> I cry a little every time I look at the DRM_MODESET_LOCK_ALL_BEGIN and
> DRM_MODESET_LOCK_ALL_END macros. :(
>
> Currently only six users... but there are ~60 calls to
> drm_modeset_lock_all{,_ctx} that I presume are to be replaced. I wonder
> if this will come back and haunt us.
>
What's the alternative? Seems like the options without the macros is
to use incorrect scope or have a bunch of retry/backoff cargo-cult
everywhere (and hope the copy source is done correctly).
>>>
>>> Yeah Sean & me had a bunch of bikesheds and this is the least worst
>>> option we could come up with. You can't make it a function because of
>>> the control flow. You don't want to open code this because it's tricky
>>> to get right, if all you want is to just grab all locks. But it is
>>> magic hidden behind a macro, which occasionally ends up hurting.
>>> -Daniel
>> So what are we doing with this problem? Should we replace at once approx. 60
>> calls?
>
> I'm confused by your question - dradual conversion is entirely orthogonal
> to what exactly we're converting too. All I added here is that we've
> discussed this at length, and the macro is the best thing we've come up
> with. I still think it's the best compromise.
>
> Flag-day conversion for over 60 calls doesn't work, no matter what.
> -Daniel
>
I agree with that. All I wanted to ask was whether I should add something
additional to this patch or not.
Thanks,
Michal
>>
>> Michal
>>>
Sean
> BR,
> Jani.
>
>
>>
>> obj = drm_mode_object_find(dev, file_priv, arg->obj_id,
>> arg->obj_type);
>> if (!obj) {
>> @@ -427,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(struct
>> drm_device *dev, void *data,
>> out_unref:
>> drm_mode_object_put(obj);
>> out:
>> - drm_modeset_unlock_all(dev);
>> + DRM_MODESET_LOCK_ALL_END(ctx, ret);
>> return ret;
>> }
>>
>> @@ -449,12 +450,13 @@ static int set_property_legacy(struct
>> drm_mode_object *obj,
>> {
>> struct drm_device *dev = prop->dev;
>> struct drm_mode_object *ref;
>> + struct drm_modeset_acquire_ctx ctx;
>> int ret = -EINVAL;
>>
>> if (!drm_property_change_valid_get(prop, prop_value, ))
>> return -EINVAL;
>>
>> - drm_modeset_lock_all(dev);
>> + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>> switch (obj->type) {
>> case DRM_MODE_OBJECT_CONNECTOR:
>> ret = drm_connector_set_obj_prop(obj, prop, prop_value);
>> @@ -468,7 +470,7 @@ static int set_property_legacy(struct
>> drm_mode_object *obj,
>> break;
>> }
>> drm_property_change_valid_put(prop, ref);
>> - drm_modeset_unlock_all(dev);
>> + DRM_MODESET_LOCK_ALL_END(ctx, ret);
>>
>> return ret;
>> }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
>>>
>>>
>>>
>
[PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings
Add a new binding of the i2c-stm32f7 driver to enable the handling of the SMBUS-Alert Signed-off-by: Alain Volmat --- Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index b50a2f420b36..04c0882c3661 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -36,6 +36,10 @@ allOf: minItems: 3 maxItems: 3 +st,smbus-alert: + description: Enable the SMBus Alert feature + $ref: /schemas/types.yaml#/definitions/flag + - if: properties: compatible: -- 2.17.1
[PATCH 2/4] i2c: addition of client reg/unreg callbacks
Addition of two callbacks reg_client and unreg_client that can be
implemented by adapter drivers in order to take action whenever a
client is being registered to it.
Signed-off-by: Alain Volmat
---
drivers/i2c/i2c-core-base.c | 11 +++
include/linux/i2c.h | 6 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 2e4560671183..4c84c6264314 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -319,6 +319,12 @@ static int i2c_device_probe(struct device *dev)
if (!client)
return 0;
+ if (client->adapter->algo->reg_client) {
+ status = client->adapter->algo->reg_client(client);
+ if (status)
+ return status;
+ }
+
driver = to_i2c_driver(dev->driver);
client->irq = client->init_irq;
@@ -417,6 +423,8 @@ static int i2c_device_probe(struct device *dev)
put_sync_adapter:
if (client->flags & I2C_CLIENT_HOST_NOTIFY)
pm_runtime_put_sync(>adapter->dev);
+ if (client->adapter->algo->reg_client)
+ client->adapter->algo->unreg_client(client);
return status;
}
@@ -445,6 +453,9 @@ static int i2c_device_remove(struct device *dev)
if (client->flags & I2C_CLIENT_HOST_NOTIFY)
pm_runtime_put(>adapter->dev);
+ if (client->adapter->algo->unreg_client)
+ client->adapter->algo->unreg_client(client);
+
return status;
}
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 45d36ba4826b..61b838caf454 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -509,6 +509,8 @@ i2c_register_board_info(int busnum, struct i2c_board_info
const *info,
* so e.g. PMICs can be accessed very late before shutdown. Optional.
* @functionality: Return the flags that this algorithm/adapter pair supports
* from the ``I2C_FUNC_*`` flags.
+ * @reg_client: Callback informing that a new client is being registered
+ * @unreg_client: Callback informing that a client is being removed
* @reg_slave: Register given client to I2C slave mode of this adapter
* @unreg_slave: Unregister given client from I2C slave mode of this adapter
*
@@ -545,6 +547,10 @@ struct i2c_algorithm {
/* To determine what the adapter supports */
u32 (*functionality)(struct i2c_adapter *adap);
+ /* To inform the adapter of the probe/remove of a client */
+ int (*reg_client)(struct i2c_client *client);
+ void (*unreg_client)(struct i2c_client *client);
+
#if IS_ENABLED(CONFIG_I2C_SLAVE)
int (*reg_slave)(struct i2c_client *client);
int (*unreg_slave)(struct i2c_client *client);
--
2.17.1
[PATCH 1/4] i2c: smbus: add core function handling SMBus host-notify
SMBus Host-Notify protocol, from the adapter point of view
consist of receiving a message from a client, including the
client address and some other data.
It can be simply handled by creating a new slave device
and registering a callback performing the parsing of the
message received from the client.
This commit introduces two new core functions
* i2c_new_smbus_host_notify_device
* i2c_free_smbus_host_notify_device
that take care of registration of the new slave device and
callback and will call i2c_handle_smbus_host_notify once a
Host-Notify event is received.
Signed-off-by: Alain Volmat
---
drivers/i2c/i2c-core-smbus.c | 105 +++
include/linux/i2c-smbus.h| 2 +
2 files changed, 107 insertions(+)
diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index b34d2ff06931..0c7e135c73e1 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -708,3 +708,108 @@ int of_i2c_setup_smbus_alert(struct i2c_adapter *adapter)
}
EXPORT_SYMBOL_GPL(of_i2c_setup_smbus_alert);
#endif
+
+struct i2c_smbus_host_notify_status {
+ bool notify_start;
+ u8 addr;
+};
+
+static int i2c_smbus_host_notify_cb(struct i2c_client *client,
+ enum i2c_slave_event event, u8 *val)
+{
+ struct i2c_smbus_host_notify_status *status = client->dev.platform_data;
+ int ret;
+
+ switch (event) {
+ case I2C_SLAVE_WRITE_REQUESTED:
+ status->notify_start = true;
+ break;
+ case I2C_SLAVE_WRITE_RECEIVED:
+ /* We only retrieve the first byte received (addr)
+* since there is currently no way to retrieve the data
+* parameter from the client.
+*/
+ if (!status->notify_start)
+ break;
+ status->addr = *val;
+ status->notify_start = false;
+ break;
+ case I2C_SLAVE_STOP:
+ ret = i2c_handle_smbus_host_notify(client->adapter,
+ status->addr);
+ if (ret < 0) {
+ dev_warn(>adapter->dev, "failed to handle
host_notify (%d)\n",
+ ret);
+ return ret;
+ }
+ break;
+ default:
+ /* Only handle necessary events */
+ break;
+ }
+
+ return 0;
+}
+
+/**
+ * i2c_new_smbus_host_notify_device - get a client for SMBus host-notify
support
+ * @adapter: the target adapter
+ * Context: can sleep
+ *
+ * Setup handling of the SMBus host-notify protocol on a given I2C bus segment.
+ *
+ * Handling is done by creating a device and its callback and handling data
+ * received via the SMBus host-notify address (0x8)
+ *
+ * This returns the client, which should be ultimately freed using
+ * i2c_free_smbus_host_notify_device(); or an ERRPTR to indicate an error.
+ */
+struct i2c_client *i2c_new_smbus_host_notify_device(struct i2c_adapter
*adapter)
+{
+ struct i2c_board_info host_notify_board_info = {
+ I2C_BOARD_INFO("smbus_host_notify", 0x08),
+ .flags = I2C_CLIENT_SLAVE,
+ };
+ struct i2c_smbus_host_notify_status *status;
+ struct i2c_client *client;
+ int ret;
+
+ status = kzalloc(sizeof(struct i2c_smbus_host_notify_status),
+GFP_KERNEL);
+ if (!status)
+ return ERR_PTR(-ENOMEM);
+
+ host_notify_board_info.platform_data = status;
+
+ client = i2c_new_client_device(adapter, _notify_board_info);
+ if (IS_ERR(client)) {
+ kfree(status);
+ return client;
+ }
+
+ ret = i2c_slave_register(client, i2c_smbus_host_notify_cb);
+ if (ret) {
+ i2c_unregister_device(client);
+ kfree(status);
+ return ERR_PTR(ret);
+ }
+
+ return client;
+}
+EXPORT_SYMBOL_GPL(i2c_new_smbus_host_notify_device);
+
+/**
+ * i2c_free_smbus_host_notify_device - free the client for SMBus host-notify
+ * support
+ * @client: the client to free
+ * Context: can sleep
+ *
+ * Free the i2c_client allocated via i2c_new_smbus_host_notify_device
+ */
+void i2c_free_smbus_host_notify_device(struct i2c_client *client)
+{
+ i2c_slave_unregister(client);
+ kfree(client->dev.platform_data);
+ i2c_unregister_device(client);
+}
+EXPORT_SYMBOL_GPL(i2c_free_smbus_host_notify_device);
diff --git a/include/linux/i2c-smbus.h b/include/linux/i2c-smbus.h
index 8c5459034f92..926f6d8ae30d 100644
--- a/include/linux/i2c-smbus.h
+++ b/include/linux/i2c-smbus.h
@@ -38,5 +38,7 @@ static inline int of_i2c_setup_smbus_alert(struct i2c_adapter
*adap)
return 0;
}
#endif
+struct i2c_client *i2c_new_smbus_host_notify_device(struct i2c_adapter
*adapter);
+void i2c_free_smbus_host_notify_device(struct i2c_client *client);
#endif /*
[PATCH 0/4] stm32-f7: Addition of SMBus Alert / Host-notify features
This serie adds SMBus Alert and SMBus Host-Notify features for the i2c-stm32f7. For that purpore, I propose two enhancements to the i2c framework. 1. Addition of host-notify client handling as part of the i2c-core-smbus so that any other i2c adapter can benefit from it, even those without specific HW support for Host-Notify. 2. Addition of two i2c_algorithm reg_client and unreg_client allowing adapter to take some actions when a client is being probed. Indeed, in case of host-notify, the binding/flag is related to the client and the adapter might want to enable the host-notify feature only when there is a client requesting the host-notify. (Since SMBus host-notify is using the address 0x08 which is a valid I2C address, keeping host-notify always enabled would make the 0x08 I2C slave address non usable). Alain Volmat (4): i2c: smbus: add core function handling SMBus host-notify i2c: addition of client reg/unreg callbacks dt-bindings: i2c-stm32: add SMBus Alert bindings i2c: stm32f7: Add SMBus-specific protocols support .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 4 + drivers/i2c/busses/Kconfig| 1 + drivers/i2c/busses/i2c-stm32f7.c | 198 +- drivers/i2c/i2c-core-base.c | 11 + drivers/i2c/i2c-core-smbus.c | 105 ++ include/linux/i2c-smbus.h | 2 + include/linux/i2c.h | 6 + 7 files changed, 317 insertions(+), 10 deletions(-) -- 2.17.1
[PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support
This patch adds the support for SMBus Host notify and SMBus Alert
extensions protocols
Signed-off-by: Alain Volmat
---
drivers/i2c/busses/Kconfig | 1 +
drivers/i2c/busses/i2c-stm32f7.c | 198 +--
2 files changed, 189 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2f6e39b41e6c..b82c2f7d7d50 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1024,6 +1024,7 @@ config I2C_STM32F7
tristate "STMicroelectronics STM32F7 I2C support"
depends on ARCH_STM32 || COMPILE_TEST
select I2C_SLAVE
+ select I2C_SMBUS
help
Enable this option to add support for STM32 I2C controller embedded
in STM32F7 SoCs.
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 9c9e10ea9199..6d02ddbc1ab4 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -14,10 +14,12 @@
* This driver is based on i2c-stm32f4.c
*
*/
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -50,6 +52,8 @@
/* STM32F7 I2C control 1 */
#define STM32F7_I2C_CR1_PECEN BIT(23)
+#define STM32F7_I2C_CR1_ALERTENBIT(22)
+#define STM32F7_I2C_CR1_SMBHEN BIT(20)
#define STM32F7_I2C_CR1_WUPEN BIT(18)
#define STM32F7_I2C_CR1_SBCBIT(16)
#define STM32F7_I2C_CR1_RXDMAENBIT(15)
@@ -121,6 +125,7 @@
(((n) & STM32F7_I2C_ISR_ADDCODE_MASK) >> 17)
#define STM32F7_I2C_ISR_DIRBIT(16)
#define STM32F7_I2C_ISR_BUSY BIT(15)
+#define STM32F7_I2C_ISR_ALERT BIT(13)
#define STM32F7_I2C_ISR_PECERR BIT(11)
#define STM32F7_I2C_ISR_ARLO BIT(9)
#define STM32F7_I2C_ISR_BERR BIT(8)
@@ -134,6 +139,7 @@
#define STM32F7_I2C_ISR_TXEBIT(0)
/* STM32F7 I2C Interrupt Clear */
+#define STM32F7_I2C_ICR_ALERTCFBIT(13)
#define STM32F7_I2C_ICR_PECCF BIT(11)
#define STM32F7_I2C_ICR_ARLOCF BIT(9)
#define STM32F7_I2C_ICR_BERRCF BIT(8)
@@ -150,7 +156,7 @@
#define STM32F7_I2C_MAX_LEN0xff
#define STM32F7_I2C_DMA_LEN_MIN0x16
-#define STM32F7_I2C_MAX_SLAVE 0x2
+#define STM32F7_I2C_MAX_SLAVE 0x3
#define STM32F7_I2C_DNF_DEFAULT0
#define STM32F7_I2C_DNF_MAX16
@@ -274,6 +280,29 @@ struct stm32f7_i2c_msg {
u8 smbus_buf[I2C_SMBUS_BLOCK_MAX + 3] __aligned(4);
};
+/**
+ * struct stm32f7_i2c_host - SMBus host specific data
+ * @client: I2C slave device that represents SMBus host
+ * @notify_start: indicate that this is the start of the notify transaction
+ * @addr: device address of SMBus device that initiate SMBus host protocol
+ */
+struct stm32f7_i2c_host {
+ struct i2c_client *client;
+ bool notify_start;
+ u8 addr;
+};
+
+/**
+ * struct stm32f7_i2c_alert - SMBus alert specific data
+ * @setup: platform data for the smbus_alert i2c client
+ * @ara: I2C slave device used to respond to the SMBus Alert with Alert
+ * Response Address
+ */
+struct stm32f7_i2c_alert {
+ struct i2c_smbus_alert_setup setup;
+ struct i2c_client *ara;
+};
+
/**
* struct stm32f7_i2c_dev - private data of the controller
* @adap: I2C adapter for this controller
@@ -301,6 +330,9 @@ struct stm32f7_i2c_msg {
* @fmp_creg: register address for clearing Fast Mode Plus bits
* @fmp_mask: mask for Fast Mode Plus bits in set register
* @wakeup_src: boolean to know if the device is a wakeup source
+ * @host_notify_cnt: atomic to know number of host_notify enabled clients
+ * @host_notify_client: SMBus host-notify client
+ * @alert: SMBus alert specific data
*/
struct stm32f7_i2c_dev {
struct i2c_adapter adap;
@@ -327,6 +359,9 @@ struct stm32f7_i2c_dev {
u32 fmp_creg;
u32 fmp_mask;
bool wakeup_src;
+ atomic_t host_notify_cnt;
+ struct i2c_client *host_notify_client;
+ struct stm32f7_i2c_alert *alert;
};
/*
@@ -1321,10 +1356,20 @@ static int stm32f7_i2c_get_free_slave_id(struct
stm32f7_i2c_dev *i2c_dev,
int i;
/*
-* slave[0] supports 7-bit and 10-bit slave address
-* slave[1] supports 7-bit slave address only
+* slave[0] support only SMBus Host address (0x8)
+* slave[1] supports 7-bit and 10-bit slave address
+* slave[2] supports 7-bit slave address only
*/
- for (i = STM32F7_I2C_MAX_SLAVE - 1; i >= 0; i--) {
+ if (atomic_read(_dev->host_notify_cnt)) {
+ if (slave->addr == 0x08) {
+ if (i2c_dev->slave[0])
+ goto fail;
+
Re: [v3] nfp: abm: Fix incomplete release of system resources in nfp_abm_vnic_set_mac()
> Thanks for your feedback, and yes, I'd like to further adjust the description > details > to make the patch more clear and better. Thanks for such a positive response. > But because Jakub seems to prefer v1, so I'm somehow confused Such a view can be reasonable. The change acceptance varies between involved contributors. > if I should submit a new version based on v1 Such a choice depends also on your willingness to clarify and improve the software situation by better commit messages. > or based on the version that has an addition of a jump target? I propose that you can offer patch series with two update steps (for example) according to the affected function implementation. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=47cf1b422e6093aee2a3e55d5e162112a2c69870#n102 1. Add a missing function call for the completion of the desired resource clean-up. 2. Adjust a bit of exception handling code so that it can be better reused at the end of this function. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=47cf1b422e6093aee2a3e55d5e162112a2c69870#n450 I am curious if you are going to answer (my) previous questions and suggestions (in constructive ways). Regards, Markus
Re: [PATCH] Fix all coding-style warnings on lm75 driver
On 05.05.2020 03:58, Guenter Roeck wrote:
> On Thu, Apr 30, 2020 at 04:05:34PM +0200, Michal Orzel wrote:
>> Check/fix all warnings generated by checkpatch.pl script on LM75 driver.
>>
>> Signed-off-by: Michal Orzel
>
> Applied, but for the future please prepend your patches with something like
> "subsystem: driver:", or for hwmon "hwmon: (driver)".
>
> Also, please keep in mind that such cleanups are not encouraged unless you
> also provide functional changes.
>
> Thanks,
> Guenter
>
I will keep it in mind.
Thanks,
Michal
>> ---
>> drivers/hwmon/lm75.c | 8 ++--
>> drivers/hwmon/lm75.h | 31 +--
>> 2 files changed, 23 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
>> index 5e63922..ba0be48 100644
>> --- a/drivers/hwmon/lm75.c
>> +++ b/drivers/hwmon/lm75.c
>> @@ -797,8 +797,10 @@ static int lm75_detect(struct i2c_client *new_client,
>>
>> /* First check for LM75A */
>> if (i2c_smbus_read_byte_data(new_client, 7) == LM75A_ID) {
>> -/* LM75A returns 0xff on unused registers so
>> - just to be sure we check for that too. */
>> +/*
>> + * LM75A returns 0xff on unused registers so
>> + * just to be sure we check for that too.
>> + */
>> if (i2c_smbus_read_byte_data(new_client, 4) != 0xff
>> || i2c_smbus_read_byte_data(new_client, 5) != 0xff
>> || i2c_smbus_read_byte_data(new_client, 6) != 0xff)
>> @@ -849,6 +851,7 @@ static int lm75_suspend(struct device *dev)
>> {
>> int status;
>> struct i2c_client *client = to_i2c_client(dev);
>> +
>> status = i2c_smbus_read_byte_data(client, LM75_REG_CONF);
>> if (status < 0) {
>> dev_dbg(>dev, "Can't read config? %d\n", status);
>> @@ -863,6 +866,7 @@ static int lm75_resume(struct device *dev)
>> {
>> int status;
>> struct i2c_client *client = to_i2c_client(dev);
>> +
>> status = i2c_smbus_read_byte_data(client, LM75_REG_CONF);
>> if (status < 0) {
>> dev_dbg(>dev, "Can't read config? %d\n", status);
>> diff --git a/drivers/hwmon/lm75.h b/drivers/hwmon/lm75.h
>> index b614e63..a398171 100644
>> --- a/drivers/hwmon/lm75.h
>> +++ b/drivers/hwmon/lm75.h
>> @@ -1,17 +1,15 @@
>> /* SPDX-License-Identifier: GPL-2.0-or-later */
>> /*
>> -lm75.h - Part of lm_sensors, Linux kernel modules for hardware
>> - monitoring
>> -Copyright (c) 2003 Mark M. Hoffman
>> -
>> -*/
>> + * lm75.h - Part of lm_sensors, Linux kernel modules for hardware monitoring
>> + * Copyright (c) 2003 Mark M. Hoffman
>> + */
>>
>> /*
>> -This file contains common code for encoding/decoding LM75 type
>> -temperature readings, which are emulated by many of the chips
>> -we support. As the user is unlikely to load more than one driver
>> -which contains this code, we don't worry about the wasted space.
>> -*/
>> + * This file contains common code for encoding/decoding LM75 type
>> + * temperature readings, which are emulated by many of the chips
>> + * we support. As the user is unlikely to load more than one driver
>> + * which contains this code, we don't worry about the wasted space.
>> + */
>>
>> #include
>>
>> @@ -20,18 +18,23 @@
>> #define LM75_TEMP_MAX 125000
>> #define LM75_SHUTDOWN 0x01
>>
>> -/* TEMP: 0.001C/bit (-55C to +125C)
>> - REG: (0.5C/bit, two's complement) << 7 */
>> +/*
>> + * TEMP: 0.001C/bit (-55C to +125C)
>> + * REG: (0.5C/bit, two's complement) << 7
>> + */
>> static inline u16 LM75_TEMP_TO_REG(long temp)
>> {
>> int ntemp = clamp_val(temp, LM75_TEMP_MIN, LM75_TEMP_MAX);
>> +
>> ntemp += (ntemp < 0 ? -250 : 250);
>> return (u16)((ntemp / 500) << 7);
>> }
>>
>> static inline int LM75_TEMP_FROM_REG(u16 reg)
>> {
>> -/* use integer division instead of equivalent right shift to
>> - guarantee arithmetic shift and preserve the sign */
>> +/*
>> + * use integer division instead of equivalent right shift to
>> + * guarantee arithmetic shift and preserve the sign
>> + */
>> return ((s16)reg / 128) * 500;
>> }
>> --
>> 2.7.4
>>
Re: [PATCH] slub: limit count of partial slabs scanned to gather statistics
On 04/05/2020 22.56, Andrew Morton wrote:
On Mon, 04 May 2020 19:07:39 +0300 Konstantin Khlebnikov
wrote:
To get exact count of free and used objects slub have to scan list of
partial slabs. This may take at long time. Scanning holds spinlock and
blocks allocations which move partial slabs to per-cpu lists and back.
Example found in the wild:
# cat /sys/kernel/slab/dentry/partial
14478538 N0=7329569 N1=7148969
# time cat /sys/kernel/slab/dentry/objects
286225471 N0=136967768 N1=149257703
real0m1.722s
user0m0.001s
sys 0m1.721s
I assume this could trigger the softlockup detector or even NMI
watchdog in some situations?
Yes, irqs are disabled here. But loop itself is pretty fast.
It requires terabytes of ram to reach common thresholds for watchdogs.
The same problem in slab was addressed in commit f728b0a5d72a ("mm, slab:
faster active and free stats") by adding more kmem cache statistics.
For slub same approach requires atomic op on fast path when object frees.
Let's simply limit count of scanned slabs and print warning.
Limit set in /sys/module/slub/parameters/max_partial_to_count.
Default is 1 which should be enough for most sane cases.
Return linear approximation if list of partials is longer than limit.
Nobody should notice difference.
That's a pretty sad "solution" :(
But I guess it's better than nothing at all, unless there are
alternative ideas?
Running this loop till the end adds more problems than gives information.
Adding new percpu or atomic counters to fast paths seems redundant even for
debugging.
Actually there is no much sense in accurate statistics for count of objects,
when there are millions of them.
Memory consumption here is defined by count and size of slabs.
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2407,16 +2407,29 @@ static inline unsigned long node_nr_objs(struct
kmem_cache_node *n)
#endif /* CONFIG_SLUB_DEBUG */
#if defined(CONFIG_SLUB_DEBUG) || defined(CONFIG_SYSFS)
+
+static unsigned long max_partial_to_count __read_mostly = 1;
+module_param(max_partial_to_count, ulong, 0644);
+
static unsigned long count_partial(struct kmem_cache_node *n,
int (*get_count)(struct page *))
{
+ unsigned long counted = 0;
unsigned long flags;
unsigned long x = 0;
struct page *page;
spin_lock_irqsave(>list_lock, flags);
- list_for_each_entry(page, >partial, slab_list)
+ list_for_each_entry(page, >partial, slab_list) {
x += get_count(page);
+
+ if (++counted > max_partial_to_count) {
+ pr_warn_once("SLUB: too much partial slabs to count all
objects, increase max_partial_to_count.\n");
+ /* Approximate total count of objects */
+ x = mult_frac(x, n->nr_partial, counted);
+ break;
+ }
+ }
spin_unlock_irqrestore(>list_lock, flags);
return x;
}
Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement lane reordering + polarity
Quoting Douglas Anderson (2020-05-04 21:36:31)
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
> remapping of eDP lanes and also polarity inversion. Both of these
> features have been described in the device tree bindings for the
> device since the beginning but were never implemented in the driver.
> Implement both of them.
>
> Part of this change also allows you to (via the same device tree
> bindings) specify to use fewer than the max number of DP lanes that
> the panel reports. This could be useful if your display supports more
> lanes but only a few are hooked up on your board.
>
> Signed-off-by: Douglas Anderson
> ---
Except for one thing below:
Reviewed-by: Stephen Boyd
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 1a125423eb07..52cca54b525f 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -707,26 +716,20 @@ static void ti_sn_bridge_enable(struct drm_bridge
> *bridge)
> int dp_rate_idx;
> unsigned int val;
> int ret = -EINVAL;
> + int max_dp_lanes;
>
> - /*
> -* Run with the maximum number of lanes that the DP sink supports.
> -*
> -* Depending use cases, we might want to revisit this later because:
> -* - It's plausible that someone may have run fewer lines to the
> -* sink than the sink actually supports, assuming that the lines
> -* will just be driven at a higher rate.
> -* - The DP spec seems to indicate that it's more important to
> minimize
> -* the number of lanes than the link rate.
> -*
> -* If we do revisit, it would be important to measure the power
> impact.
> -*/
> - pdata->dp_lanes = ti_sn_get_max_lanes(pdata);
> + max_dp_lanes = ti_sn_get_max_lanes(pdata);
> + pdata->dp_lanes = min(pdata->dp_lanes, max_dp_lanes);
>
> /* DSI_A lane config */
> val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
Not a problem in this patch, but maybe this can be SN_MAX_DP_LANES -
pdata->dsi->lanes now.
> regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
>CHA_DSI_LANES_MASK, val);
>
> + regmap_write(pdata->regmap, SN_LN_ASSIGN_REG, pdata->ln_assign);
> + regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, LN_POLRS_MASK,
> + pdata->ln_polrs << LN_POLRS_OFFSET);
> +
> /* set dsi clk frequency value */
> ti_sn_bridge_set_dsi_rate(pdata);
>
> @@ -1063,6 +1066,50 @@ static int ti_sn_setup_gpio_controller(struct
> ti_sn_bridge *pdata)
> return ret;
> }
>
> +static void ti_sn_bridge_parse_lanes(struct ti_sn_bridge *pdata,
> +struct device_node *np)
> +{
> + u32 lane_assignments[SN_MAX_DP_LANES] = { 0, 1, 2, 3 };
> + u32 lane_polarities[SN_MAX_DP_LANES] = { };
> + struct device_node *endpoint;
> + u8 ln_assign = 0;
> + u8 ln_polrs = 0;
Do we need to assign to 0 to start? Seems like no?
> + int dp_lanes;
> + int i;
> +
> + /*
> +* Read config from the device tree about lane remapping and lane
> +* polarities. These are optional and we assume identity map and
> +* normal polarity if nothing is specified. It's OK to specify just
> +* data-lanes but not lane-polarities but not vice versa.
> +*/
> + endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
> + dp_lanes = of_property_count_u32_elems(endpoint, "data-lanes");
> + if (dp_lanes > 0) {
> + of_property_read_u32_array(endpoint, "data-lanes",
> + lane_assignments, dp_lanes);
> + of_property_read_u32_array(endpoint, "lane-polarities",
> + lane_polarities, dp_lanes);
> + } else {
> + dp_lanes = SN_MAX_DP_LANES;
> + }
Needs an of_node_put(endpoint) here for the
of_graph_get_endpoint_by_regs() above.
> +
> + /*
> +* Convert into register format. Loop over all lanes even if
> +* data-lanes had fewer elements so that we nicely initialize
> +* the LN_ASSIGN register.
> +*/
> + for (i = SN_MAX_DP_LANES - 1; i >= 0; i--) {
> + ln_assign = ln_assign << LN_ASSIGN_WIDTH |
> lane_assignments[i];
> + ln_polrs = ln_polrs << 1 | lane_polarities[i];
> + }
> +
> + /* Stash in our struct for when we power on */
> + pdata->dp_lanes = dp_lanes;
> + pdata->ln_assign = ln_assign;
> + pdata->ln_polrs = ln_polrs;
> +}
Re: [PATCH] ASoC: qcom: Use devm_platform_ioremap_resource_byname() to simplify code
Hi Tang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on asoc/for-next]
[also build test ERROR on v5.7-rc4 next-20200504]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Tang-Bin/ASoC-qcom-Use-devm_platform_ioremap_resource_byname-to-simplify-code/20200505-051041
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
for-next
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
sound/soc/qcom/lpass-cpu.c: In function 'asoc_qcom_lpass_cpu_platform_probe':
>> sound/soc/qcom/lpass-cpu.c:445:21: error: expected ';' before 'if'
445 | "lpass-lpaif")
| ^
| ;
446 | if (IS_ERR((void const __force *)drvdata->lpaif)) {
| ~~
vim +445 sound/soc/qcom/lpass-cpu.c
415
416 int asoc_qcom_lpass_cpu_platform_probe(struct platform_device *pdev)
417 {
418 struct lpass_data *drvdata;
419 struct device_node *dsp_of_node;
420 struct lpass_variant *variant;
421 struct device *dev = >dev;
422 const struct of_device_id *match;
423 int ret, i, dai_id;
424
425 dsp_of_node = of_parse_phandle(pdev->dev.of_node, "qcom,adsp",
0);
426 if (dsp_of_node) {
427 dev_err(>dev, "DSP exists and holds audio
resources\n");
428 return -EBUSY;
429 }
430
431 drvdata = devm_kzalloc(>dev, sizeof(struct lpass_data),
432 GFP_KERNEL);
433 if (!drvdata)
434 return -ENOMEM;
435 platform_set_drvdata(pdev, drvdata);
436
437 match = of_match_device(dev->driver->of_match_table, dev);
438 if (!match || !match->data)
439 return -EINVAL;
440
441 drvdata->variant = (struct lpass_variant *)match->data;
442 variant = drvdata->variant;
443
444 drvdata->lpaif = devm_platform_ioremap_resource_byname(pdev,
> 445 "lpass-lpaif")
446 if (IS_ERR((void const __force *)drvdata->lpaif)) {
447 dev_err(>dev, "error mapping reg resource: %ld\n",
448 PTR_ERR((void const __force
*)drvdata->lpaif));
449 return PTR_ERR((void const __force *)drvdata->lpaif);
450 }
451
452 lpass_cpu_regmap_config.max_register =
LPAIF_WRDMAPER_REG(variant,
453 variant->wrdma_channels
+
454
variant->wrdma_channel_start);
455
456 drvdata->lpaif_map = devm_regmap_init_mmio(>dev,
drvdata->lpaif,
457 _cpu_regmap_config);
458 if (IS_ERR(drvdata->lpaif_map)) {
459 dev_err(>dev, "error initializing regmap: %ld\n",
460 PTR_ERR(drvdata->lpaif_map));
461 return PTR_ERR(drvdata->lpaif_map);
462 }
463
464 if (variant->init)
465 variant->init(pdev);
466
467 for (i = 0; i < variant->num_dai; i++) {
468 dai_id = variant->dai_driver[i].id;
469 drvdata->mi2s_osr_clk[dai_id] = devm_clk_get(>dev,
470
variant->dai_osr_clk_names[i]);
471 if (IS_ERR(drvdata->mi2s_osr_clk[dai_id])) {
472 dev_warn(>dev,
473 "%s() error getting optional %s: %ld\n",
474 __func__,
475 variant->dai_osr_clk_names[i],
476 PTR_ERR(drvdata->mi2s_osr_clk[dai_id]));
477
478 drvdata->mi2s_osr_clk[dai_id] = NULL;
479 }
480
481 drvdata->mi2s
Re: [PATCH] drm/bridge: ti-sn65dsi86: Fix off-by-one error in clock choice
Quoting Douglas Anderson (2020-05-04 21:32:29)
> If the rate in our table is _equal_ to the rate we want then it's OK
> to pick it. It doesn't need to be greater than the one we want.
>
> Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
> Signed-off-by: Douglas Anderson
> ---
Reviewed-by: Stephen Boyd
Re: [PATCH v4 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Boris,
On 4/5/2020 4:58 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 16:50:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 4/5/2020 3:17 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 15:15:08 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
Thank you very much for the prompt review and suggestions...
On 4/5/2020 3:08 pm, Boris Brezillon wrote:
On Mon, 4 May 2020 10:02:35 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
Hi Boris,
On 30/4/2020 9:01 pm, Boris Brezillon wrote:
On Thu, 30 Apr 2020 14:36:00 +0200
Boris Brezillon wrote:
On Thu, 30 Apr 2020 17:07:03 +0800
"Ramuthevar, Vadivel MuruganX"
wrote:
The question is, is it the same value we have in nand_pa or it is
different?
Different address which is 0xE140 NAND_BASE_PHY address.
Then why didn't you tell me they didn't match when I suggested to pass
sorry, because you keep asking nand_pa after that only I realized that.
nand_pa? So now the question is, what does this address represent?
EBU-MODULE
_ ___
| | ||NAND CTRL |
| FPI BUS |==>| CS0(0x174) | 0xE100( 0xE14/0xE1C) NAND_PHY_BASE
|_| |_CS1(0x17C)_|__ |
EBU_CONRTROLLER_BASE : 0xE0F0_
HSNAND_BASE: 0xE100_
NAND_CS0: 0xE140_
NAND_CS1: 0xE1C0_
MEM_REGION_BASE_CS0: 0x17400 (internal to ebu controller )
MEM_REGION_BASE_CS1: 0x17C00
Hm, I wonder if we shouldn't use a 'ranges' property to describe this
address translation. Something like
ebu@xxx {
ranges = <0x1740 0xe140 0x1000>,
<0x17c0 0xe1c0 0x1000>;
reg = <0x1740>, <0x17c0>;
reg-names = "cs-0", "cs-1";
}
The translated address (0xE1X0) will be available in res->start,
and the non-translated one (0x17X0) can be retrieved with
of_get_address(). All you'd have to do then would be calculate the
mask:
mask = (translated_address & original_address) >> 22;
num_comp_bits = fls(mask);
WARN_ON(mask != GENMASK(num_comp_bits - 1, 0));
Which allows you to properly set the ADDR_SEL() register without
relying on some hardcoded values:
writel(original_address | EBU_ADDR_SEL_REGEN |
EBU_ADDR_COMP_BITS(num_comp_bits),
ebu_host->ebu + EBU_ADDR_SEL(csid));
That's quite important if we want to merge the xway NAND driver with
this one.
Looks like the translation is done at the FPI bus declaration level (see
[1]). We really need to see the big picture to take a wise decision
about the bindings. Would you mind pasting your dsti/dts files
somewhere? It feels like the NAND controller is a sub-part of a more
generic 'memory' controller, in which case the NAND controller should be
declared as a child of this generic memory bus (called localbus in [1],
but maybe EBU is more accurate).
[1]https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/blob/master/target/linux/lantiq/files-4.14/arch/mips/boot/dts/vr9.dtsi#L162
ebu_nand: ebu_nand@e0f0 {
compatible = "intel,lgm-ebu-nand";
reg = <0xe0f0 0x100
0xe100 0x300
0xe140 0x8
0xe1c0 0x1>;
reg-names = "ebunand", "hsnand", "nand_cs0", nand_cs1";
dmas = < 8>, < 9>;
dma-names = "ebu_rx", "ebu_tx";
clocks = < LGM_GCLK_EBU>;
};
_nand {
status = "disabled";
nand,cs = <1>;
nand-ecc-mode = "hw";
pinctrl-names = "default";
pinctrl-0 = <_nand_base _cs1>;
};
Ok. If I understand the SoC topology correctly it should actually be
something like that:
{
...
fpi@x {
compatible = "intel,lgm-fpi", "simple-bus";
/* You might have other ranges to define here */
ranges = <0x1600 0xe000 0x100>;
...
Sorry, we do not have fpi tree node in our dts/dtsi file instead we have
the below one.. , that also not included the major peripherals
controllers node.
/* Special part from CPU core */
core: core {
compatible = "intel,core", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ioapic1: interrupt-controller@fec0 {
#interrupt-cells = <2>;
#address-cells = <0>;
compatible = "intel,ce4100-ioapic";
interrupt-controller;
reg = <0xfec0 0x1000>;
nr_entries = <256>;
};
Re: [PATCH v7 3/3] phy: intel: Add driver support for ComboPhy
On 04-05-20, 17:32, Dilip Kota wrote:
>
> On 5/4/2020 5:20 PM, Vinod Koul wrote:
> > On 04-05-20, 16:26, Dilip Kota wrote:
> > > On 5/4/2020 3:29 PM, Vinod Koul wrote:
> > > > On 30-04-20, 15:15, Dilip Kota wrote:
> > > >
> > > > > + u32 mask, u32 val)
> > > > > +{
> > > > > + u32 reg_val;
> > > > > +
> > > > > + reg_val = readl(base + reg);
> > > > > + reg_val &= ~mask;
> > > > > + reg_val |= FIELD_PREP(mask, val);
> > > > > + writel(reg_val, base + reg);
> > > > bypassing regmap here... why?
> > > It is not regmap address, one of the below two addresses are passed to
> > > this
> > > function.
> > okay, perhaps add a comment somewhere that regmap is not used for this
> > base?
> I dont see a need of adding a comment, describing don't do regmap here.
Driver uses regmap except here, which seems odd hence explanation
required for this.
> >
> > > struct intel_combo_phy {
> > > ...
> > > void __iomem *app_base;
> > > void __iomem *cr_base;
> > > ...
> > > }
> >
> > > > > +static int intel_cbphy_calibrate(struct phy *phy)
> > > > > +{
> > > > > + struct intel_cbphy_iphy *iphy = phy_get_drvdata(phy);
> > > > > + struct intel_combo_phy *cbphy = iphy->parent;
> > > > > + void __iomem *cr_base = cbphy->cr_base;
> > > > > + int val, ret, id;
> > > > > +
> > > > > + if (cbphy->phy_mode != PHY_XPCS_MODE)
> > > > > + return 0;
> > > > > +
> > > > > + id = PHY_ID(iphy);
> > > > > +
> > > > > + /* trigger auto RX adaptation */
> > > > > + combo_phy_w32_off_mask(cr_base, CR_ADDR(PCS_XF_ATE_OVRD_IN_2,
> > > > > id),
> > > > > +ADAPT_REQ_MSK, 3);
> > > > > + /* Wait RX adaptation to finish */
> > > > > + ret = readl_poll_timeout(cr_base + CR_ADDR(PCS_XF_RX_ADAPT_ACK,
> > > > > id),
> > > > > + val, val & RX_ADAPT_ACK_BIT, 10, 5000);
> > > > > + if (ret)
> > > > > + dev_err(cbphy->dev, "RX Adaptation failed!\n");
> > > > you want to continue her and not return error?
> > > Next step is stopping the Adaptation, it should be done in both error and
> > > success case.
> > Again documenting this helps, pls add some comments on this behaviour
> Comments are already in place, mentioning Start and Stop of Rx Adaptation.
> And Stop is being is done as Start is triggered, so not needed to mention
> error and success.
Ok
--
~Vinod
Re: [PATCH] iommu: Relax ACS requirement for RCiEP devices.
On Mon, 4 May 2020 21:42:16 -0700
Ashok Raj wrote:
> PCIe Spec recommends we can relax ACS requirement for RCIEP devices.
>
> PCIe 5.0 Specification.
> 6.12 Access Control Services (ACS)
> Implementation of ACS in RCiEPs is permitted but not required. It is
> explicitly permitted that, within a single Root Complex, some RCiEPs
> implement ACS and some do not. It is strongly recommended that Root Complex
> implementations ensure that all accesses originating from RCiEPs
> (PFs and VFs) without ACS capability are first subjected to processing by
> the Translation Agent (TA) in the Root Complex before further decoding and
> processing. The details of such Root Complex handling are outside the scope
> of this specification.
>
> Since Linux didn't give special treatment to allow this exception, certain
> RCiEP MFD devices are getting grouped in a single iommu group. This
> doesn't permit a single device to be assigned to a guest for instance.
>
> In one vendor system: Device 14.x were grouped in a single IOMMU group.
>
> /sys/kernel/iommu_groups/5/devices/:00:14.0
> /sys/kernel/iommu_groups/5/devices/:00:14.2
> /sys/kernel/iommu_groups/5/devices/:00:14.3
>
> After the patch:
> /sys/kernel/iommu_groups/5/devices/:00:14.0
> /sys/kernel/iommu_groups/5/devices/:00:14.2
> /sys/kernel/iommu_groups/6/devices/:00:14.3 <<< new group
>
> 14.0 and 14.2 are integrated devices, but legacy end points.
> Whereas 14.3 was a PCIe compliant RCiEP.
>
> 00:14.3 Network controller: Intel Corporation Device 9df0 (rev 30)
> Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
>
> This permits assigning this device to a guest VM.
>
> Fixes: f096c061f552 ("iommu: Rework iommu_group_get_for_pci_dev()")
> Signed-off-by: Ashok Raj
> To: Joerg Roedel
> To: Bjorn Helgaas
> Cc: linux-kernel@vger.kernel.org
> Cc: io...@lists.linux-foundation.org
> Cc: Lu Baolu
> Cc: Alex Williamson
> Cc: Darrel Goeddel
> Cc: Mark Scott ,
> Cc: Romil Sharma
> Cc: Ashok Raj
> ---
> drivers/iommu/iommu.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 2b471419e26c..5744bd65f3e2 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1187,7 +1187,20 @@ static struct iommu_group
> *get_pci_function_alias_group(struct pci_dev *pdev,
> struct pci_dev *tmp = NULL;
> struct iommu_group *group;
>
> - if (!pdev->multifunction || pci_acs_enabled(pdev, REQ_ACS_FLAGS))
> + /*
> + * PCI Spec 5.0, Section 6.12 Access Control Service
> + * Implementation of ACS in RCiEPs is permitted but not required.
> + * It is explicitly permitted that, within a single Root
> + * Complex, some RCiEPs implement ACS and some do not. It is
> + * strongly recommended that Root Complex implementations ensure
> + * that all accesses originating from RCiEPs (PFs and VFs) without
> + * ACS capability are first subjected to processing by the Translation
> + * Agent (TA) in the Root Complex before further decoding and
> + * processing.
> + */
Is the language here really strong enough to make this change? ACS is
an optional feature, so being permitted but not required is rather
meaningless. The spec is also specifically avoiding the words "must"
or "shall" and even when emphasized with "strongly", we still only have
a recommendation that may or may not be honored. This seems like a
weak basis for assuming that RCiEPs universally honor this
recommendation. Thanks,
Alex
> + if (!pdev->multifunction ||
> + (pci_pcie_type(pdev) == PCI_EXP_TYPE_RC_END) ||
> + pci_acs_enabled(pdev, REQ_ACS_FLAGS))
> return NULL;
>
> for_each_pci_dev(tmp) {
Re: [PATCH v8 0/5] Add SS/HS-USB changes for Qualcomm SM8150 chipset
On 04-05-20, 16:54, Wesley Cheng wrote: > This series adds support for the Synopsis 7nm HSPHY USB driver being > used in QCOM chipsets. The HSPHY register map differs compared to > other PHY revisions. In addition, modifications and updates are done > to the QMP driver to add new registers/offsets, and to update the > initialization sequence for enabling the SSUSB path on SM8150. Applied all, thanks. Pls note the dt-binding patch had a trailing line at the end of file, I have stripped that while applying. -- ~Vinod
Re: fs: jfs: fix a possible data race in txBegin()
> I am not sure how to add the tag "Fixes"... How helpful do you find the available software documentation? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=47cf1b422e6093aee2a3e55d5e162112a2c69870#n183 > I need to find which previous commit add the code about txBegin()? I suggest to take another look at corresponding source code places by a command like “git blame”. https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Gits Regards, Markus
Re: [PATCH 1/6] dt-bindings: phy: meson8b-usb2: Convert to json-schema
On 04-05-20, 10:31, Joe Perches wrote:
> On Mon, 2020-05-04 at 12:55 +0200, hex dump wrote:
> > On Sat, May 2, 2020 at 1:48 PM Martin Blumenstingl
> > wrote:
> > > Now that we have the DT validation in place, let's convert the device
> > > tree bindings for the Amlogic Meson8, Meson8b, Meson8m2 and GXBB USB2
> > > PHY over to a YAML schema.
> > >
> > > While here, also add the fallback compatible string
> > > "amlogic,meson-gxbb-usb2-phy" which is already used in
> > > arch/arm/boot/dts/meson{,8,8b}.dtsi.
> > >
> > > Signed-off-by: Martin Blumenstingl
> >
> > Tested-by: hexdump
>
> Is the kernel now accepting "Tested-by" lines from robots?
Should we not? bots have been given Reported-by...
>
> If hexdump0...@googlemail.com is not a robot, can you please use
> your full legal name instead?
Looking at emails, this doesnt seem a bot, so I am asking for full legal
name for these to be added.
Thanks
--
~Vinod
Re: [PATCH] kcsan: Add test suite
On Mon, Apr 27, 2020 at 11:23 PM 'Marco Elver' via kasan-dev wrote: > > On Mon, 27 Apr 2020 at 16:35, Marco Elver wrote: > > > > This adds KCSAN test focusing on behaviour of the integrated runtime. > > Tests various race scenarios, and verifies the reports generated to > > console. Makes use of KUnit for test organization, and the Torture > > framework for test thread control. > > > > Signed-off-by: Marco Elver > > --- > > +KUnit devs > We had some discussions on how to best test sanitizer runtimes, and we > believe that this test is what testing sanitizer runtimes should > roughly look like. Note that, for KCSAN there are various additional > complexities like multiple threads, and report generation isn't > entirely deterministic (need to run some number of iterations to get > reports, may get multiple reports, etc.). Thanks very much for writing the test. I do think that it goes a little outside what we'd normally expect of a unit test (notably with the issues around determinism and threading), but it's good to see KUnit being pushed in new directions a bit. The biggest issue in my mind is the possibility that the non-determinism of the tests could cause false positives. If we're trying to run as many KUnit tests as possible as part of continuous integration systems or as a condition for accepting patches, having flaky tests could be annoying. The KCSAN tests seem to break/fail as-is when run on single-core machines (at least, under qemu), so some way of documenting this as a requirement would probably be necessary, too. One possibility would be to add support for "skipped" tests to KUnit (the TAP specification allows for it), so that the KCSAN test could detect cases where it's not reliable, and skip itself (leaving a note as to why). In the short term, though, we'd absolutely need some documentation around the dependencies for the test. (For the record, the failures I saw were all due to running under qemu emulating as a uniprocessor/single-core machine: with CONFIG_PREEMPT_VOLUNTARY, it would just hang after creating the first couple of threads. With CONFIG_PREEMPT, the tests completed, but the majority of them failed.) > The main thing, however, is that we want to verify the actual output > (or absence of it) to console. This is what the KCSAN test does using > the 'console' tracepoint. Could KUnit provide some generic > infrastructure to check console output, like is done in the test here? > Right now I couldn't say what the most useful generalization of this > would be (without it just being a wrapper around the console > tracepoint), because the way I've decided to capture and then match > console output is quite test-specific. For now we can replicate this > logic on a per-test basis, but it would be extremely useful if there > was a generic interface that KUnit could provide in future. This is something we've discussed here a couple of times as well. While I'll confess to being a little bit wary of having tests rely too heavily on console output: it risks being a bit fragile if the exact contents or formatting of messages change, or ends up having a lot of string formatting and/or parsing code in the tests. I do agree, though, that it probably needs to be at least a part of testing things like sanitizers where the ultimate goal is to produce console output. I'm not exactly sure how we'd implement it yet, so it's probably not going to happen extremely soon, but what you have here looks to me like a good example we can generalise as needed. Cheers, -- David
[PATCH -next] drm/radeon: fix unsigned comparison with 0
Fixes warning because pipe is unsigned long and can never be negtative
vers/gpu/drm/radeon/radeon_kms.c:831:11: warning:
comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (pipe < 0 || pipe >= rdev->num_crtc) {
drivers/gpu/drm/radeon/radeon_kms.c:857:11: warning:
comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (pipe < 0 || pipe >= rdev->num_crtc) {
Reported-by: Hulk Robot
Signed-off-by: ChenTao
---
drivers/gpu/drm/radeon/radeon_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 372962358a18..c5d1dc9618a4 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -828,7 +828,7 @@ int radeon_enable_vblank_kms(struct drm_crtc *crtc)
unsigned long irqflags;
int r;
- if (pipe < 0 || pipe >= rdev->num_crtc) {
+ if (pipe >= rdev->num_crtc) {
DRM_ERROR("Invalid crtc %d\n", pipe);
return -EINVAL;
}
@@ -854,7 +854,7 @@ void radeon_disable_vblank_kms(struct drm_crtc *crtc)
struct radeon_device *rdev = dev->dev_private;
unsigned long irqflags;
- if (pipe < 0 || pipe >= rdev->num_crtc) {
+ if (pipe >= rdev->num_crtc) {
DRM_ERROR("Invalid crtc %d\n", pipe);
return;
}
--
2.22.0
Re: [PATCH v4 10/12] OPP: Add support for setting interconnect-tags
On 05-05-20, 01:52, Sibi Sankar wrote: > Add support for setting tags on icc paths associated with > the opp_table. > > Signed-off-by: Sibi Sankar > --- > drivers/opp/of.c | 25 +++-- > 1 file changed, 19 insertions(+), 6 deletions(-) Maybe this should be part of Georgi's series ? -- viresh
Re: [PATCH 04/15] ath10k: fix gcc-10 zero-length-bounds warnings
"Gustavo A. R. Silva" writes:
> On 5/4/20 06:54, Kalle Valo wrote:
>> "Gustavo A. R. Silva" writes:
>>
>>> Hi Arnd,
>>>
>>> On 4/30/20 16:30, Arnd Bergmann wrote:
gcc-10 started warning about out-of-bounds access for zero-length
arrays:
In file included from drivers/net/wireless/ath/ath10k/core.h:18,
from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
drivers/net/wireless/ath/ath10k/htt_rx.c: In function
'ath10k_htt_rx_tx_fetch_ind':
drivers/net/wireless/ath/ath10k/htt.h:1683:17: warning: array subscript
65535 is outside the bounds of an interior zero-length array 'struct
htt_tx_fetch_record[0]' [-Wzero-length-bounds]
1683 | return (void *)>records[le16_to_cpu(ind->num_records)];
| ^~~~
drivers/net/wireless/ath/ath10k/htt.h:1676:29: note: while referencing
'records'
1676 | struct htt_tx_fetch_record records[0];
| ^~~
The structure was already converted to have a flexible-array member in
the past, but there are two zero-length members in the end and only
one of them can be a flexible-array member.
Swap the two around to avoid the warning, as 'resp_ids' is not accessed
in a way that causes a warning.
Fixes: 3ba225b506a2 ("treewide: Replace zero-length array with
flexible-array member")
Fixes: 22e6b3bc5d96 ("ath10k: add new htt definitions")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/ath10k/htt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index e7096a73c6ca..7621f0a3dc77 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1673,8 +1673,8 @@ struct htt_tx_fetch_ind {
__le32 token;
__le16 num_resp_ids;
__le16 num_records;
- struct htt_tx_fetch_record records[0];
- __le32 resp_ids[]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
+ __le32 resp_ids[0]; /* ath10k_htt_get_tx_fetch_ind_resp_ids() */
+ struct htt_tx_fetch_record records[];
} __packed;
static inline void *
>>>
>>> The treewide patch is an experimental change and, as this change only
>>> applies
>>> to my -next tree, I will carry this patch in it, so other people don't have
>>> to worry about this at all.
>>
>> Gustavo, why do you have ath10k patches in your tree? I prefer that
>> ath10k patches go through my ath.git tree so that they are reviewed and
>> tested.
>>
>
> I just wanted to test out a mechanical change. I will remove it from my tree
> now and will send a patch to you so you can apply it to your ath.git tree.
Great, thanks.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH V3 10/16] arm64/cpufeature: Add remaining feature bits in ID_AA64PFR0 register
On 05/02/2020 02:33 PM, Anshuman Khandual wrote:
Enable MPAM and SEL2 features bits in ID_AA64PFR0 register as per ARM DDI
0487F.a specification.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Suzuki K Poulose
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Will Deacon
Signed-off-by: Anshuman Khandual
---
arch/arm64/include/asm/sysreg.h | 2 ++
arch/arm64/kernel/cpufeature.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 40eaf89f1032..c93ea6613f51 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -641,6 +641,8 @@
#define ID_AA64PFR0_CSV2_SHIFT56
#define ID_AA64PFR0_DIT_SHIFT 48
#define ID_AA64PFR0_AMU_SHIFT 44
+#define ID_AA64PFR0_MPAM_SHIFT 40
+#define ID_AA64PFR0_SEL2_SHIFT 36
#define ID_AA64PFR0_SVE_SHIFT 32
#define ID_AA64PFR0_RAS_SHIFT 28
#define ID_AA64PFR0_GIC_SHIFT 24
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index dbedcae28061..f5a39e040804 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -217,6 +217,8 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
ID_AA64PFR0_CSV2_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64PFR0_DIT_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE,
ID_AA64PFR0_AMU_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64PFR0_MPAM_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64PFR0_SEL2_SHIFT, 4, 0),
Both of them must be hidden. And also need to check the impact of
exposing this to the guests, especially MPAM.
Suzuki
Re: [PATCH v4 06/12] cpufreq: qcom: Update the bandwidth levels on frequency change
On 05-05-20, 01:52, Sibi Sankar wrote: > Add support to parse optional OPP table attached to the cpu node when > the OPP bandwidth values are populated. This allows for scaling of > DDR/L3 bandwidth levels with frequency change. > > Signed-off-by: Sibi Sankar What about using opp_set_rate instead ? -- viresh
Re: [PATCH V3 09/16] arm64/cpufeature: Add remaining feature bits in ID_AA64ISAR0 register
On 05/02/2020 02:33 PM, Anshuman Khandual wrote:
Enable TLB features bit in ID_AA64ISAR0 register as per ARM DDI 0487F.a
specification.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Suzuki K Poulose
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Will Deacon
Signed-off-by: Anshuman Khandual
---
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/kernel/cpufeature.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 0f34927f52b9..40eaf89f1032 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -597,6 +597,7 @@
/* id_aa64isar0 */
#define ID_AA64ISAR0_RNDR_SHIFT 60
+#define ID_AA64ISAR0_TLB_SHIFT 56
#define ID_AA64ISAR0_TS_SHIFT 52
#define ID_AA64ISAR0_FHM_SHIFT48
#define ID_AA64ISAR0_DP_SHIFT 44
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f4e15e355aee..dbedcae28061 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -174,6 +174,7 @@ static bool __system_matches_cap(unsigned int n);
*/
static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64ISAR0_RNDR_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
ID_AA64ISAR0_TLB_SHIFT, 4, 0),
I don't see any reason why this should be VISIBLE to the userspace.
Suzuki
[PATCH v3] KVM: nVMX: Skip IBPB when switching between vmcs01 and vmcs02
Skip the Indirect Branch Prediction Barrier that is triggered on a VMCS
switch when running with spectre_v2_user=on/auto if the switch is
guaranteed to be between two VMCSes in the same guest, i.e. between
vmcs01 and vmcs02. The IBPB is intended to prevent one guest from
attacking another, which is unnecessary in the nested case as it's the
same guest from KVM's perspective.
This all but eliminates the overhead observed for nested VMX transitions
when running with CONFIG_RETPOLINE=y and spectre_v2_user=on/auto, which
can be significant, e.g. roughly 3x on current systems.
Reported-by: Alexander Graf
Cc: KarimAllah Raslan
Cc: sta...@vger.kernel.org
Fixes: 15d45071523d ("KVM/x86: Add IBPB support")
Signed-off-by: Sean Christopherson
---
v3: Switch back to passing 'struct loaded_vmcs buddy', but keep the WARN
if the buddy VMCS isn't already loaded as well as the comment as to
why skipping IBPB in the nested case is ok. [Paolo]
v2: Pass a boolean to indicate a nested VMCS switch and instead WARN if
the buddy VMCS is not already loaded. [Alex]
arch/x86/kvm/vmx/nested.c | 2 +-
arch/x86/kvm/vmx/vmx.c| 18 ++
arch/x86/kvm/vmx/vmx.h| 3 ++-
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 2c36f3f53108..1a02bdfeeb2b 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -303,7 +303,7 @@ static void vmx_switch_vmcs(struct kvm_vcpu *vcpu, struct
loaded_vmcs *vmcs)
cpu = get_cpu();
prev = vmx->loaded_vmcs;
vmx->loaded_vmcs = vmcs;
- vmx_vcpu_load_vmcs(vcpu, cpu);
+ vmx_vcpu_load_vmcs(vcpu, cpu, prev);
vmx_sync_vmcs_host_state(vmx, prev);
put_cpu();
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 3ab6ca6062ce..06ee0572b929 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1311,10 +1311,12 @@ static void vmx_vcpu_pi_load(struct kvm_vcpu *vcpu, int
cpu)
pi_set_on(pi_desc);
}
-void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu)
+void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu,
+ struct loaded_vmcs *buddy)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
bool already_loaded = vmx->loaded_vmcs->cpu == cpu;
+ struct vmcs *prev;
if (!already_loaded) {
loaded_vmcs_clear(vmx->loaded_vmcs);
@@ -1333,10 +1335,18 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu)
local_irq_enable();
}
- if (per_cpu(current_vmcs, cpu) != vmx->loaded_vmcs->vmcs) {
+ prev = per_cpu(current_vmcs, cpu);
+ if (prev != vmx->loaded_vmcs->vmcs) {
per_cpu(current_vmcs, cpu) = vmx->loaded_vmcs->vmcs;
vmcs_load(vmx->loaded_vmcs->vmcs);
- indirect_branch_prediction_barrier();
+
+ /*
+* No indirect branch prediction barrier needed when switching
+* the active VMCS within a guest, e.g. on nested VM-Enter.
+* The L1 VMM can protect itself with retpolines, IBPB or IBRS.
+*/
+ if (!buddy || WARN_ON_ONCE(buddy->vmcs != prev))
+ indirect_branch_prediction_barrier();
}
if (!already_loaded) {
@@ -1377,7 +1387,7 @@ void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
- vmx_vcpu_load_vmcs(vcpu, cpu);
+ vmx_vcpu_load_vmcs(vcpu, cpu, NULL);
vmx_vcpu_pi_load(vcpu, cpu);
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index b5e773267abe..d3d48acc6bd9 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -320,7 +320,8 @@ struct kvm_vmx {
};
bool nested_vmx_allowed(struct kvm_vcpu *vcpu);
-void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu);
+void vmx_vcpu_load_vmcs(struct kvm_vcpu *vcpu, int cpu,
+ struct loaded_vmcs *buddy);
void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
int allocate_vpid(void);
void free_vpid(int vpid);
--
2.26.0
Re: [PATCH v4 04/12] OPP: Add and export helper to update voltage
On 05-05-20, 01:52, Sibi Sankar wrote: > Add and export 'dev_pm_opp_update_voltage' to update the voltage of an > opp for a given frequency. This will be useful to update the opps with > voltages read back from firmware. > > Signed-off-by: Sibi Sankar Have a look at dev_pm_opp_adjust_voltage(). -- viresh
[PATCH] iommu: Relax ACS requirement for RCiEP devices.
PCIe Spec recommends we can relax ACS requirement for RCIEP devices.
PCIe 5.0 Specification.
6.12 Access Control Services (ACS)
Implementation of ACS in RCiEPs is permitted but not required. It is
explicitly permitted that, within a single Root Complex, some RCiEPs
implement ACS and some do not. It is strongly recommended that Root Complex
implementations ensure that all accesses originating from RCiEPs
(PFs and VFs) without ACS capability are first subjected to processing by
the Translation Agent (TA) in the Root Complex before further decoding and
processing. The details of such Root Complex handling are outside the scope
of this specification.
Since Linux didn't give special treatment to allow this exception, certain
RCiEP MFD devices are getting grouped in a single iommu group. This
doesn't permit a single device to be assigned to a guest for instance.
In one vendor system: Device 14.x were grouped in a single IOMMU group.
/sys/kernel/iommu_groups/5/devices/:00:14.0
/sys/kernel/iommu_groups/5/devices/:00:14.2
/sys/kernel/iommu_groups/5/devices/:00:14.3
After the patch:
/sys/kernel/iommu_groups/5/devices/:00:14.0
/sys/kernel/iommu_groups/5/devices/:00:14.2
/sys/kernel/iommu_groups/6/devices/:00:14.3 <<< new group
14.0 and 14.2 are integrated devices, but legacy end points.
Whereas 14.3 was a PCIe compliant RCiEP.
00:14.3 Network controller: Intel Corporation Device 9df0 (rev 30)
Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
This permits assigning this device to a guest VM.
Fixes: f096c061f552 ("iommu: Rework iommu_group_get_for_pci_dev()")
Signed-off-by: Ashok Raj
To: Joerg Roedel
To: Bjorn Helgaas
Cc: linux-kernel@vger.kernel.org
Cc: io...@lists.linux-foundation.org
Cc: Lu Baolu
Cc: Alex Williamson
Cc: Darrel Goeddel
Cc: Mark Scott ,
Cc: Romil Sharma
Cc: Ashok Raj
---
drivers/iommu/iommu.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 2b471419e26c..5744bd65f3e2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1187,7 +1187,20 @@ static struct iommu_group
*get_pci_function_alias_group(struct pci_dev *pdev,
struct pci_dev *tmp = NULL;
struct iommu_group *group;
- if (!pdev->multifunction || pci_acs_enabled(pdev, REQ_ACS_FLAGS))
+ /*
+* PCI Spec 5.0, Section 6.12 Access Control Service
+* Implementation of ACS in RCiEPs is permitted but not required.
+* It is explicitly permitted that, within a single Root
+* Complex, some RCiEPs implement ACS and some do not. It is
+* strongly recommended that Root Complex implementations ensure
+* that all accesses originating from RCiEPs (PFs and VFs) without
+* ACS capability are first subjected to processing by the Translation
+* Agent (TA) in the Root Complex before further decoding and
+* processing.
+*/
+ if (!pdev->multifunction ||
+ (pci_pcie_type(pdev) == PCI_EXP_TYPE_RC_END) ||
+pci_acs_enabled(pdev, REQ_ACS_FLAGS))
return NULL;
for_each_pci_dev(tmp) {
--
2.7.4
[PATCH] drm/bridge: ti-sn65dsi86: Implement lane reordering + polarity
The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
remapping of eDP lanes and also polarity inversion. Both of these
features have been described in the device tree bindings for the
device since the beginning but were never implemented in the driver.
Implement both of them.
Part of this change also allows you to (via the same device tree
bindings) specify to use fewer than the max number of DP lanes that
the panel reports. This could be useful if your display supports more
lanes but only a few are hooked up on your board.
Signed-off-by: Douglas Anderson
---
This patch is based upon my my outstanding series[1] not because there
is any real requirement but simply to avoid merge conflicts. I
believe that my previous series is ready to land. If, however, you'd
prefer that I rebase this patch somewhere atop something else then
please shout.
[1] https://lore.kernel.org/r/20200430194617.197510-1-diand...@chromium.org
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 75 ++-
1 file changed, 62 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 1a125423eb07..52cca54b525f 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -50,8 +50,12 @@
#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG 0x38
#define SN_CHA_VERTICAL_FRONT_PORCH_REG0x3A
+#define SN_LN_ASSIGN_REG 0x59
+#define LN_ASSIGN_WIDTH 2
#define SN_ENH_FRAME_REG 0x5A
#define VSTREAM_ENABLEBIT(3)
+#define LN_POLRS_OFFSET 4
+#define LN_POLRS_MASK 0xf0
#define SN_DATA_FORMAT_REG 0x5B
#define BPP_18_RGBBIT(0)
#define SN_HPD_DISABLE_REG 0x5C
@@ -98,6 +102,7 @@
#define SN_REGULATOR_SUPPLY_NUM4
+#define SN_MAX_DP_LANES4
#define SN_NUM_GPIOS 4
/**
@@ -115,6 +120,8 @@
* @enable_gpio: The GPIO we toggle to enable the bridge.
* @supplies: Data for bulk enabling/disabling our regulators.
* @dp_lanes: Count of dp_lanes we're using.
+ * @ln_assign:Value to program to the LN_ASSIGN register.
+ * @ln_polr: Value for the 4-bit LN_POLRS field of SN_ENH_FRAME_REG.
*
* @gchip:If we expose our GPIOs, this is used.
* @gchip_output: A cache of whether we've set GPIOs to output. This
@@ -140,6 +147,8 @@ struct ti_sn_bridge {
struct gpio_desc*enable_gpio;
struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM];
int dp_lanes;
+ u8 ln_assign;
+ u8 ln_polrs;
struct gpio_chipgchip;
DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
@@ -707,26 +716,20 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
int dp_rate_idx;
unsigned int val;
int ret = -EINVAL;
+ int max_dp_lanes;
- /*
-* Run with the maximum number of lanes that the DP sink supports.
-*
-* Depending use cases, we might want to revisit this later because:
-* - It's plausible that someone may have run fewer lines to the
-* sink than the sink actually supports, assuming that the lines
-* will just be driven at a higher rate.
-* - The DP spec seems to indicate that it's more important to minimize
-* the number of lanes than the link rate.
-*
-* If we do revisit, it would be important to measure the power impact.
-*/
- pdata->dp_lanes = ti_sn_get_max_lanes(pdata);
+ max_dp_lanes = ti_sn_get_max_lanes(pdata);
+ pdata->dp_lanes = min(pdata->dp_lanes, max_dp_lanes);
/* DSI_A lane config */
val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
CHA_DSI_LANES_MASK, val);
+ regmap_write(pdata->regmap, SN_LN_ASSIGN_REG, pdata->ln_assign);
+ regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, LN_POLRS_MASK,
+ pdata->ln_polrs << LN_POLRS_OFFSET);
+
/* set dsi clk frequency value */
ti_sn_bridge_set_dsi_rate(pdata);
@@ -1063,6 +1066,50 @@ static int ti_sn_setup_gpio_controller(struct
ti_sn_bridge *pdata)
return ret;
}
+static void ti_sn_bridge_parse_lanes(struct ti_sn_bridge *pdata,
+struct device_node *np)
+{
+ u32 lane_assignments[SN_MAX_DP_LANES] = { 0, 1, 2, 3 };
+ u32 lane_polarities[SN_MAX_DP_LANES] = { };
+ struct device_node *endpoint;
+ u8 ln_assign = 0;
+ u8 ln_polrs = 0;
+ int dp_lanes;
+ int i;
+
+ /*
+*
[PATCH] drm/bridge: ti-sn65dsi86: Fix off-by-one error in clock choice
If the rate in our table is _equal_ to the rate we want then it's OK
to pick it. It doesn't need to be greater than the one we want.
Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 6ad688b320ae..be000b0ca56b 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -475,7 +475,7 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct
ti_sn_bridge *pdata)
1000 * pdata->dp_lanes * DP_CLK_FUDGE_DEN);
for (i = 1; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
- if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
+ if (ti_sn_bridge_dp_rate_lut[i] >= dp_rate_mhz)
break;
return i;
--
2.26.2.526.g744177e7f7-goog
Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper
> > I changed it to make code cleaner: for such basic operation there are > > too many conditions if we will keep it inside the kmsg_dump(). > > However, if being able to set always_kmsg_dump dynamically during > > runtime is deemed important, I can change it back to be checked in > > kmsg_dump. > > If you agree that we do not have to modify this variable dynamically, > I will also change the permission here: > module_param_named(always_kmsg_dump, always_kmsg_dump, bool, S_IRUGO | > S_IWUSR); Hi Sergey, After thinking about this. I will move this logic back to kmsg_dump(), to keep the current behavior where kmsg_dump can be modified during runtime. Thank you, Pasha
Re: [PATCH 2/2] x86/resctrl: Support CPUID enumeration of MBM counter width
Hi Borislav,
On 5/4/2020 12:56 AM, Borislav Petkov wrote:
> Hi,
>
> On Sun, May 03, 2020 at 11:51:00AM -0700, Reinette Chatre wrote:
>> I am struggling with what should follow ...
>
> Since a diff is better than a thousand words :-) see below.
>
Thank you so much for providing the details. Your explanation is clear
to me but I do have one clarification question ...
> @@ -597,6 +598,8 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
> x86_amd_ls_cfg_ssbd_mask = 1ULL << bit;
> }
> }
> +
> + resctrl_cpu_detect(c);
> }
>
...
> @@ -322,6 +323,11 @@ static void early_init_intel(struct cpuinfo_x86 *c)
> detect_ht_early(c);
> }
>
> +static void bsp_init_intel(struct cpuinfo_x86 *c)
> +{
> + resctrl_cpu_detect(c);
> +}
> +
> #ifdef CONFIG_X86_32
> /*
> * Early probe support logic for ppro memory erratum #50
> @@ -961,6 +967,7 @@ static const struct cpu_dev intel_cpu_dev = {
> #endif
> .c_detect_tlb = intel_detect_tlb,
> .c_early_init = early_init_intel,
> + .c_bsp_init = bsp_init_intel,
> .c_init = init_intel,
> .c_x86_vendor = X86_VENDOR_INTEL,
> };
> diff --git a/arch/x86/kernel/cpu/resctrl/core.c
> b/arch/x86/kernel/cpu/resctrl/core.c
> index d8cc5223b7ce..5e5955aa6593 100644
> --- a/arch/x86/kernel/cpu/resctrl/core.c
> +++ b/arch/x86/kernel/cpu/resctrl/core.c
> @@ -22,7 +22,7 @@
> #include
>
> #include
> -#include
> +#include
> #include "internal.h"
>
> /* Mutex to protect rdtgroup access. */
> @@ -958,6 +958,35 @@ static __init void rdt_init_res_defs(void)
>
> static enum cpuhp_state rdt_online;
>
> +/* Runs once on the BSP during boot. */
> +void resctrl_cpu_detect(struct cpuinfo_x86 *c)
> +{
> + if (!cpu_has(c, X86_FEATURE_CQM_LLC)) {
> + c->x86_cache_max_rmid = -1;
> + c->x86_cache_occ_scale = -1;
> + c->x86_cache_mbm_width_offset = -1;
> + return;
> + }
> +
> + /* will be overridden if occupancy monitoring exists */
> + c->x86_cache_max_rmid = cpuid_ebx(0xf);
> +
> + if (cpu_has(c, X86_FEATURE_CQM_OCCUP_LLC) ||
> + cpu_has(c, X86_FEATURE_CQM_MBM_TOTAL) ||
> + cpu_has(c, X86_FEATURE_CQM_MBM_LOCAL)) {
> + u32 eax, ebx, ecx, edx;
> +
> + /* QoS sub-leaf, EAX=0Fh, ECX=1 */
> + cpuid_count(0xf, 1, , , , );
> +
> + c->x86_cache_max_rmid = ecx;
> + c->x86_cache_occ_scale = ebx;
> +
> + if (c->x86_vendor == X86_VENDOR_INTEL)
> + c->x86_cache_mbm_width_offset = eax & 0xff;
> + }
> +}
> +
resctrl_cpu_detect() is now identical among vendors. Do we still need
the c_bsp_init helpers? Could we not perhaps call resctrl_cpu_detect()
directly from early_identify_cpu()?
Thank you
Reinette
Re: [PATCH 1/4] dma-mapping: move the remaining DMA API calls out of line
On 17/04/2020 17:58, Christoph Hellwig wrote: > On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote: >> And the fact they were exported leaves possibility that there is a >> driver somewhere relying on these symbols or distro kernel won't build >> because the symbol disappeared from exports (I do not know what KABI >> guarantees or if mainline kernel cares). > > We absolutely do not care. In fact for abuses of APIs that drivers > should not use we almost care to make them private and break people > abusing them. ok :) >> I do not care in particular but >> some might, a line separated with empty lines in the commit log would do. > > I'll add a blurb for the next version. Has it gone anywhere? Thanks, -- Alexey
Re: [PATCH v4 0/7] clean up redundant 'kvm_run' parameters
Paolo Bonzini, any opinion on this? Thanks and best, Tianjia On 2020/4/27 12:35, Tianjia Zhang wrote: In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu' structure. For historical reasons, many kvm-related function parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This patch does a unified cleanup of these remaining redundant parameters. This series of patches has completely cleaned the architecture of arm64, mips, ppc, and s390 (no such redundant code on x86). Due to the large number of modified codes, a separate patch is made for each platform. On the ppc platform, there is also a redundant structure pointer of 'kvm_run' in 'vcpu_arch', which has also been cleaned separately. --- v4 change: mips: fixes two errors in entry.c. v3 change: Keep the existing `vcpu->run` in the function body unchanged. v2 change: s390 retains the original variable name and minimizes modification. Tianjia Zhang (7): KVM: s390: clean up redundant 'kvm_run' parameters KVM: arm64: clean up redundant 'kvm_run' parameters KVM: PPC: Remove redundant kvm_run from vcpu_arch KVM: PPC: clean up redundant 'kvm_run' parameters KVM: PPC: clean up redundant kvm_run parameters in assembly KVM: MIPS: clean up redundant 'kvm_run' parameters KVM: MIPS: clean up redundant kvm_run parameters in assembly arch/arm64/include/asm/kvm_coproc.h | 12 +-- arch/arm64/include/asm/kvm_host.h| 11 +-- arch/arm64/include/asm/kvm_mmu.h | 2 +- arch/arm64/kvm/handle_exit.c | 36 +++ arch/arm64/kvm/sys_regs.c| 13 ++- arch/mips/include/asm/kvm_host.h | 32 +-- arch/mips/kvm/emulate.c | 59 arch/mips/kvm/entry.c| 21 ++--- arch/mips/kvm/mips.c | 14 +-- arch/mips/kvm/trap_emul.c| 114 ++- arch/mips/kvm/vz.c | 26 ++ arch/powerpc/include/asm/kvm_book3s.h| 16 ++-- arch/powerpc/include/asm/kvm_host.h | 1 - arch/powerpc/include/asm/kvm_ppc.h | 27 +++--- arch/powerpc/kvm/book3s.c| 4 +- arch/powerpc/kvm/book3s.h| 2 +- arch/powerpc/kvm/book3s_64_mmu_hv.c | 12 +-- arch/powerpc/kvm/book3s_64_mmu_radix.c | 4 +- arch/powerpc/kvm/book3s_emulate.c| 10 +- arch/powerpc/kvm/book3s_hv.c | 64 ++--- arch/powerpc/kvm/book3s_hv_nested.c | 12 +-- arch/powerpc/kvm/book3s_interrupts.S | 17 ++-- arch/powerpc/kvm/book3s_paired_singles.c | 72 +++--- arch/powerpc/kvm/book3s_pr.c | 33 --- arch/powerpc/kvm/booke.c | 39 arch/powerpc/kvm/booke.h | 8 +- arch/powerpc/kvm/booke_emulate.c | 2 +- arch/powerpc/kvm/booke_interrupts.S | 9 +- arch/powerpc/kvm/bookehv_interrupts.S| 10 +- arch/powerpc/kvm/e500_emulate.c | 15 ++- arch/powerpc/kvm/emulate.c | 10 +- arch/powerpc/kvm/emulate_loadstore.c | 32 +++ arch/powerpc/kvm/powerpc.c | 72 +++--- arch/powerpc/kvm/trace_hv.h | 6 +- arch/s390/kvm/kvm-s390.c | 23 +++-- virt/kvm/arm/arm.c | 6 +- virt/kvm/arm/mmio.c | 11 ++- virt/kvm/arm/mmu.c | 5 +- 38 files changed, 392 insertions(+), 470 deletions(-)
Re: perf build error with gcc 10 on arm and aarch64
Hi Thomas,
[ + Mathieu/Mike/Suzuki ]
On Mon, May 04, 2020 at 10:22:27PM +0300, Thomas Backlund wrote:
> This is building perf from kernel-5.6.10 on armv7hl and aarch64:
>
> Compiler is gcc 10.1.0-RC
>
>
> LD perf-in.o
> ld: arch/perf-in.o: in function `.LANCHOR0':
> /home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118:
> multiple definition of `traceid_list';
> util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/perf/util/cs-etm.h:118:
> first defined here
> make[3]: ***
> [/home/iurt/rpmbuild/BUILD/kernel-arm/linux-5.6/tools/build/Makefile.build:145:
> perf-in.o] Error 1
>
> LD perf-in.o
> ld:
> arch/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/include/../../util/cs-etm.h:118:
> multiple definition of `traceid_list';
> util/perf-in.o:/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/perf/util/cs-etm.h:118:
> first defined here
> make[3]: ***
> [/home/iurt/rpmbuild/BUILD/kernel-aarch64/linux-5.6/tools/build/Makefile.build:145:
> perf-in.o] Error 1
> make[2]: *** [Makefile.perf:616: perf-in.o] Error 2
> make[1]: *** [Makefile.perf:225: sub-make] Error 2
> make: *** [Makefile:70: all] Error 2
>
>
> The same build succeeds with gcc 9.3.0
Thanks for reporting the issue.
Could you help confirm if below change can resolve this issue?
Thanks,
Leo
---8<---
Subject: [PATCH] perf cs-etm: Move defined of traceid_list
The variable 'traceid_list' is defined in the header file cs-etm.h,
if multiple C files include cs-etm.h the compiler might complaint for
multiple definition of 'traceid_list'.
To fix multiple definition error, move the definition of 'traceid_list'
into cs-etm.c.
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm.c | 3 +++
tools/perf/util/cs-etm.h | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 62d2f9b9ce1b..381d9708e9bd 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -94,6 +94,9 @@ struct cs_etm_queue {
struct cs_etm_traceid_queue **traceid_queues;
};
+/* RB tree for quick conversion between traceID and metadata pointers */
+static struct intlist *traceid_list;
+
static int cs_etm__update_queues(struct cs_etm_auxtrace *etm);
static int cs_etm__process_queues(struct cs_etm_auxtrace *etm);
static int cs_etm__process_timeless_queues(struct cs_etm_auxtrace *etm,
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index 650ecc2a6349..4ad925d6d799 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -114,9 +114,6 @@ enum cs_etm_isa {
CS_ETM_ISA_T32,
};
-/* RB tree for quick conversion between traceID and metadata pointers */
-struct intlist *traceid_list;
-
struct cs_etm_queue;
struct cs_etm_packet {
--
2.17.1
Re: [PATCH] fs: jfs: fix a possible data race in txBegin()
On 2020/5/5 0:15, Markus Elfring wrote: Thus, a data race can occur for tblk->flag. To fix this data race, the spinlock log->gclock is used in txBegin(). This data race is found by our concurrency fuzzer. How do you think about a wording variant like the following? Change description: A data race can occur for the data structure member “flag”. This data race was found by our concurrency fuzzer. Thus use the spin lock “gclock” for the resetting of five data structure members in this function implementation. Would you like to add the tag “Fixes” to the commit message? Thanks, Markus. I am not sure how to add the tag "Fixes"... I need to find which previous commit add the code about txBegin()? Best wishes, Jia-Ju Bai
Re: [RFC Patch v1 2/4] irqchip/gic-v3: Add support to handle SGI as pseudo NMI
On Fri, 1 May 2020 at 18:33, Sumit Garg wrote: > > Hi Marc, > > On Thu, 30 Apr 2020 at 17:43, Sumit Garg wrote: > > > > On Thu, 30 Apr 2020 at 14:43, Marc Zyngier wrote: > > > > > > On Thu, 30 Apr 2020 12:50:28 +0530 > > > Sumit Garg wrote: > > > > > > > Hi Marc, > > > > > > > > On Wed, 29 Apr 2020 at 13:53, Marc Zyngier wrote: > > > > > > [...] > > > > > > > > What I would like is for the arch code to request these interrupts as > > > > > normal interrupts, for which there is one problem to solve: how do you > > > > > find out about the Linux IRQ number for a given IPI. Or rather, how > > > > > do you get rid of the requirement to have IPI numbers at all and just > > > > > say "give me a per-cpu interrupt that I can use as an IPI, and by the > > > > > way here's the handler you can call". > > > > > > > > I think what you are looking for here is something that could be > > > > sufficed via enabling "CONFIG_GENERIC_IRQ_IPI" framework for arm64/arm > > > > architectures. It's currently used for mips architecture. Looking at > > > > its implementation, I think it should be possible to hook up SGIs > > > > under new IPI irq_domain for GICv2/v3. > > > > > > > > So with this framework we should be able to dynamically allocate IPIs > > > > and use common APIs such as request_irq()/request_nmi() to tell IPI > > > > specific handlers. > > > > > > > > If this approach looks sane to you then I can start working on a PoC > > > > implementation for arm64. > > > > > > I can't say I'm keen. This IPI framework doesn't really work for the > > > GIC: > > > > > > - it requires a separate irqdomain to be able to guarantee that you > > > allocate the hwirq in the SGI range. What is the point? > > > - it creates yet another level of indirection on IPI injection > > > > > > This framework was created to deal with two cases: > > > - systems that can't represent their IPI with a single hwirq spanning > > > all the CPUs > > > - "accelerator cores" that don't run Linux > > > > > > The GIC architecture avoids the first point, and I don't even want to > > > think of the second one. > > > > > > Also, it doesn't solve the initial problem, which is to bootstrap the > > > whole thing. The IPI framework relies on an irqdomain to be created the > > > first place. This would mean teaching the arch code about the > > > intricacies of irqdomains, FW nodes and other terrible things. All > > > things which are better hidden in the GIC drivers (not to mention the > > > other horror stories that are the RPi-2/3 irqchip and the Huawei GIC > > > knock-off). > > > > > > What I have in mind is to replace the set_smp_cross_call() with > > > something that passes the required set of information (interrupt range, > > > at the very least). The only thing that I plan to reuse from the IPI > > > framework is the chip->ipi_send_mask() callback. > > > > > > > Fair enough, I will just pass the allocated interrupt range base > > instead of set_smp_cross_call() and use __ipi_send_mask() to invoke a > > particular IPI. > > Thinking more about this, there seems to be multiple irqchip drivers > registering softirq API via set_smp_cross_call(). So we need to > introduce a new API instead of replacing set_smp_cross_call() under > "CONFIG_GENERIC_IRQ_IPI" macro until all drivers switch to IPIs as > full interrupts. > > BTW, could we take up this generalization as follow-up work as it > seems to be independent of current IPI NMI work? > > > > > And to request an arch specific IPI as NMI, will use > > arch_get_ipinr_nmi() and in turn use request_percpu_nmi() to turn that > > particular IPI as NMI. > > I have updated the second patch [1] in my tree to incorporate these > changes. The updated commit log is as follows: > > commit 25c96663126264ec758c49a4a01a9c285f4ccc61 > Author: Sumit Garg > Date: Wed Apr 22 16:29:59 2020 +0530 > > irqchip/gic-v3: Setup arch specific IPI as pseudo NMI > > Add support to mark arch specific IPI as pseudo NMI. Currently its used > to allow arm64 specific IPI_CALL_NMI_FUNC to be marked as pseudo NMI. > > Brief description of changes: > - Update NMI setup/teardown routines for SGIs. > - Enable NMI support prior to gic_smp_init(). > - Setup custom flow handler for SGI setup as NMI. > - Request, prepare and enable arch specific IPI as per CPU NMI using > common APIs. > > Signed-off-by: Sumit Garg > > Please have a look and let me know if this is something you were looking for. > In case there are no major objections to this approach, I will post complete v2 patch-set (alongwith Marc's patches) for detailed review. -Sumit > [1] > https://git.linaro.org/people/sumit.garg/linux.git/commit/?h=kgdb-nmi=25c96663126264ec758c49a4a01a9c285f4ccc61 > > -Sumit > > > > Thanks, > > > > > > M. > > > -- > > > Jazz is not dead. It just smells funny...
Re: [PATCH] docs: dt: fix broken links due to txt->yaml renames
On Mon, May 4, 2020 at 12:56 PM Uwe Kleine-König wrote: > > Hi Sam, > > On Mon, May 04, 2020 at 07:45:22PM +0200, Sam Ravnborg wrote: > > On Mon, May 04, 2020 at 11:30:20AM +0200, Mauro Carvalho Chehab wrote: > > > There are some new broken doc links due to yaml renames > > > at DT. Developers should really run: > > > > > > ./scripts/documentation-file-ref-check > > > > > > in order to solve those issues while submitting patches. > > Would love if some bot could do this for me on any patches that creates > > .yaml files or so. > > I know I will forget this and it can be automated. > > If I get a bot mail that my patch would broke a link I would > > have it fixed before it hits any tree. I can probably add this to what I'm already checking. Not completely automated though as it depends on me to review before sending. > What about adding a check to check_patch? That would be the best way to get submitters to do this. Rob
Re: [PATCH v6 6/7] dt-bindings: input: Add docs for ADC driven joystick.
On Sun, 3 May 2020 19:14:50 +0200, Artur Rojek wrote: > Add documentation for the adc-joystick driver, used to provide support > for joysticks connected over ADC. > > Signed-off-by: Artur Rojek > Tested-by: Paul Cercueil > Reviewed-by: Rob Herring > --- > > Changes: > > v2: - Add `reg` property to axis subnode in order to enumerate the axes, > - rename `linux,abs-code` property to `linux,code`, > - drop `linux,` prefix from the remaining properties of axis subnode > > v3: no change > > v4: - remove "bindings" from the unique identifier string, > - replace `|` with `>` for all description properties, > - specify the number of items for `io-channels`, > - correct the regex pattern of `axis` property, > - specify the value range of `reg` property for each axis, > - put `abs-range` properties under `allOf` > > v5: add `a-f` to the regex pattern of `axis` property > > v6: no change > > .../bindings/input/adc-joystick.yaml | 121 ++ > 1 file changed, 121 insertions(+) > create mode 100644 Documentation/devicetree/bindings/input/adc-joystick.yaml > My bot found errors running 'make dt_binding_check' on your patch: Error: Documentation/devicetree/bindings/input/adc-joystick.example.dts:24.31-32 syntax error FATAL ERROR: Unable to parse input tree scripts/Makefile.lib:312: recipe for target 'Documentation/devicetree/bindings/input/adc-joystick.example.dt.yaml' failed make[1]: *** [Documentation/devicetree/bindings/input/adc-joystick.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs Makefile:1300: recipe for target 'dt_binding_check' failed make: *** [dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1282045 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit.
Re: [PATCH net-next 1/7] dt-binding: ti: am65x: document common platform time sync cpts module
On Fri, 1 May 2020 23:50:05 +0300, Grygorii Strashko wrote: > Document device tree bindings for TI AM654/J721E SoC The Common Platform > Time Sync (CPTS) module. The CPTS module is used to facilitate host control > of time sync operations. Main features of CPTS module are: > - selection of multiple external clock sources > - 64-bit timestamp mode in ns with ppm and nudge adjustment. > - control of time sync events via interrupt or polling > - hardware timestamp of ext. events (HWx_TS_PUSH) > - periodic generator function outputs (TS_GENFx) > - PPS in combination with timesync router > - Depending on integration it enables compliance with the IEEE 1588-2008 > standard for a precision clock synchronization protocol, Ethernet Enhanced > Scheduled Traffic Operations (CPTS_ESTFn) and PCIe Subsystem Precision Time > Measurement (PTM). > > Signed-off-by: Grygorii Strashko > --- > .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 7 + > .../bindings/net/ti,k3-am654-cpts.yaml| 152 ++ > 2 files changed, 159 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml > My bot found errors running 'make dt_binding_check' on your patch: Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/net/ti,k3-am654-cpts.yaml# Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.6/dist-packages/dtschema/schemas/net/ti,am654-cpts.yaml' Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.example.dts' failed make[1]: *** [Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.example.dts] Error 255 make[1]: *** Waiting for unfinished jobs Makefile:1300: recipe for target 'dt_binding_check' failed make: *** [dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1281460 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit.
Re: [PATCH net-next 1/7] dt-binding: ti: am65x: document common platform time sync cpts module
On Fri, May 01, 2020 at 11:50:05PM +0300, Grygorii Strashko wrote: > Document device tree bindings for TI AM654/J721E SoC The Common Platform > Time Sync (CPTS) module. The CPTS module is used to facilitate host control > of time sync operations. Main features of CPTS module are: > - selection of multiple external clock sources > - 64-bit timestamp mode in ns with ppm and nudge adjustment. > - control of time sync events via interrupt or polling > - hardware timestamp of ext. events (HWx_TS_PUSH) > - periodic generator function outputs (TS_GENFx) > - PPS in combination with timesync router > - Depending on integration it enables compliance with the IEEE 1588-2008 > standard for a precision clock synchronization protocol, Ethernet Enhanced > Scheduled Traffic Operations (CPTS_ESTFn) and PCIe Subsystem Precision Time > Measurement (PTM). > > Signed-off-by: Grygorii Strashko > --- > .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 7 + > .../bindings/net/ti,k3-am654-cpts.yaml| 152 ++ > 2 files changed, 159 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml > > diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml > b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml > index 78bf511e2892..0f3fde45e200 100644 > --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml > +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml > @@ -144,6 +144,13 @@ patternProperties: > description: >CPSW MDIO bus. > > + "^cpts$": Fixed strings go under 'properties'. > +type: object > +allOf: > + - $ref: "ti,am654-cpts.yaml#" > +description: > + CPSW Common Platform Time Sync (CPTS) module. > + > required: >- compatible >- reg > diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml > b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml > new file mode 100644 > index ..1b535d41e5c6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml > @@ -0,0 +1,152 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/net/ti,am654-cpts.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: The TI AM654x/J721E Common Platform Time Sync (CPTS) module Device > Tree Bindings > + > +maintainers: > + - Grygorii Strashko > + - Sekhar Nori > + > +description: |+ > + The TI AM654x/J721E CPTS module is used to facilitate host control of time > + sync operations. > + Main features of CPTS module are > + - selection of multiple external clock sources > + - Software control of time sync events via interrupt or polling > + - 64-bit timestamp mode in ns with PPM and nudge adjustment. > + - hardware timestamp push inputs (HWx_TS_PUSH) > + - timestamp counter compare output (TS_COMP) > + - timestamp counter bit output (TS_SYNC) > + - periodic Generator function outputs (TS_GENFx) > + - Ethernet Enhanced Scheduled Traffic Operations (CPTS_ESTFn) (TSN) > + - external hardware timestamp push inputs (HWx_TS_PUSH) timestamping > + > + Depending on integration it enables compliance with the IEEE 1588-2008 > + standard for a precision clock synchronization protocol, Ethernet Enhanced > + Scheduled Traffic Operations (CPTS_ESTFn) and PCIe Subsystem Precision > Time > + Measurement (PTM). > + > + TI AM654x/J721E SoCs has several similar CPTS modules integrated into the > + different parts of the system which could be synchronized with each other > + - Main CPTS > + - MCU CPSW CPTS with IEEE 1588-2008 support > + - PCIe subsystem CPTS for PTM support > + > + Depending on CPTS module integration and when CPTS is integral part of > + another module (MCU CPSW for example) "compatible" and "reg" can > + be omitted - parent module is fully responsible for CPTS enabling and > + configuration. That's fine, but you should still have compatible and reg. > + > +properties: > + $nodename: > +pattern: "^cpts(@.*|-[0-9a-f])*$" > + > + compatible: > +oneOf: > + - const: ti,am65-cpts > + - const: ti,j721e-cpts > + > + reg: > +maxItems: 1 > +description: > + The physical base address and size of CPTS IO range Wrong indentation. > + > + reg-names: > +items: > + - const: cpts Don't really need *-names when there's only one and you haven't picked very meaningful names. > + > + clocks: > +description: CPTS reference clock > + > + clock-names: > +items: > + - const: cpts > + > + interrupts-extended: Use 'interrupts' here, the tooling will fixup things to allow both. > +items: > + - description: CPTS events interrupt > + > + interrupt-names: > +items: > + - const: "cpts" Don't need quotes. > + > + ti,cpts-ext-ts-inputs: > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +
[PATCH v1 3/5] [media] mtk-mdp: handle vpu_wdt_reg_handler() errors during probe
This is a cleanup to better handle errors during MDP probe.
Signed-off-by: ei...@chromium.org
Signed-off-by: Eizan Miyamoto
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index c20ac7681c6f..f974242663dc 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -188,8 +188,12 @@ static int mtk_mdp_probe(struct platform_device *pdev)
}
mdp->vpu_dev = vpu_get_plat_device(pdev);
- vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
- VPU_RST_MDP);
+ ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
+ VPU_RST_MDP);
+ if (ret) {
+ dev_err(>dev, "Failed to register reset handler\n");
+ goto err_wdt_reg;
+ }
platform_set_drvdata(pdev, mdp);
@@ -206,6 +210,8 @@ static int mtk_mdp_probe(struct platform_device *pdev)
err_set_max_seg_size:
+err_wdt_reg:
+
err_m2m_register:
v4l2_device_unregister(>v4l2_dev);
--
2.26.2.526.g744177e7f7-goog
Re: [RFC net-next 1/3] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX325x (AC3x)
Hi Ido,
On Sat, May 02, 2020 at 06:20:49PM +0300, Vadym Kochan wrote:
> Hi Ido,
>
> On Thu, Mar 05, 2020 at 04:49:37PM +0200, Ido Schimmel wrote:
> > On Tue, Feb 25, 2020 at 04:30:54PM +, Vadym Kochan wrote:
> > > +int mvsw_pr_port_learning_set(struct mvsw_pr_port *port, bool learn)
> > > +{
> > > + return mvsw_pr_hw_port_learning_set(port, learn);
> > > +}
> > > +
> > > +int mvsw_pr_port_flood_set(struct mvsw_pr_port *port, bool flood)
> > > +{
> > > + return mvsw_pr_hw_port_flood_set(port, flood);
> > > +}
> >
> > Flooding and learning are per-port attributes? Not per-{port, VLAN} ?
> > If so, you need to have various restrictions in the driver in case
> > someone configures multiple vlan devices on top of a port and enslaves
> > them to different bridges.
Yes, and there is no support for vlan device on top of the port.
> >
> > > +
> > > +
> > > + INIT_LIST_HEAD(>vlans_list);
> > > + port->pvid = MVSW_PR_DEFAULT_VID;
> >
> > If you're using VID 1, then you need to make sure that user cannot
> > configure a VLAN device with with this VID. If possible, I suggest that
> > you use VID 4095, as it cannot be configured from user space.
> >
> > I'm actually not entirely sure why you need a default VID.
> >
>
> > > +mvsw_pr_port_vlan_bridge_join(struct mvsw_pr_port_vlan *port_vlan,
> > > + struct mvsw_pr_bridge_port *br_port,
> > > + struct netlink_ext_ack *extack)
> > > +{
> > > + struct mvsw_pr_port *port = port_vlan->mvsw_pr_port;
> > > + struct mvsw_pr_bridge_vlan *br_vlan;
> > > + u16 vid = port_vlan->vid;
> > > + int err;
> > > +
> > > + if (port_vlan->bridge_port)
> > > + return 0;
> > > +
> > > + err = mvsw_pr_port_flood_set(port, br_port->flags & BR_FLOOD);
> > > + if (err)
> > > + return err;
> > > +
> > > + err = mvsw_pr_port_learning_set(port, br_port->flags & BR_LEARNING);
> > > + if (err)
> > > + goto err_port_learning_set;
> >
> > It seems that learning and flooding are not per-{port, VLAN} attributes,
> > so I'm not sure why you have this here.
> >
> > The fact that you don't undo this in mvsw_pr_port_vlan_bridge_leave()
> > tells me it should not be here.
> >
>
> > +
> > > +void
> > > +mvsw_pr_port_vlan_bridge_leave(struct mvsw_pr_port_vlan *port_vlan)
> > > +{
> > > + struct mvsw_pr_port *port = port_vlan->mvsw_pr_port;
> > > + struct mvsw_pr_bridge_vlan *br_vlan;
> > > + struct mvsw_pr_bridge_port *br_port;
> > > + int port_count;
> > > + u16 vid = port_vlan->vid;
> > > + bool last_port, last_vlan;
> > > +
> > > + br_port = port_vlan->bridge_port;
> > > + last_vlan = list_is_singular(_port->vlan_list);
> > > + port_count =
> > > + mvsw_pr_bridge_vlan_port_count_get(br_port->bridge_device, vid);
> > > + br_vlan = mvsw_pr_bridge_vlan_find(br_port, vid);
> > > + last_port = port_count == 1;
> > > + if (last_vlan) {
> > > + mvsw_pr_fdb_flush_port(port, MVSW_PR_FDB_FLUSH_MODE_DYNAMIC);
> > > + } else if (last_port) {
> > > + mvsw_pr_fdb_flush_vlan(port->sw, vid,
> > > +MVSW_PR_FDB_FLUSH_MODE_DYNAMIC);
> > > + } else {
> > > + mvsw_pr_fdb_flush_port_vlan(port, vid,
> > > + MVSW_PR_FDB_FLUSH_MODE_DYNAMIC);
> >
> > If you always flush based on {port, VID}, then why do you need the other
> > two?
> >
>
> > +
> > > +static int mvsw_pr_port_obj_attr_set(struct net_device *dev,
> > > + const struct switchdev_attr *attr,
> > > + struct switchdev_trans *trans)
> > > +{
> > > + int err = 0;
> > > + struct mvsw_pr_port *port = netdev_priv(dev);
> > > +
> > > + switch (attr->id) {
> > > + case SWITCHDEV_ATTR_ID_PORT_STP_STATE:
> > > + err = -EOPNOTSUPP;
> >
> > You don't support STP?
>
> Not, yet. But it will be in the next submission or official patch.
> >
> > > + break;
>
> > > + default:
> > > + kfree(switchdev_work);
> > > + return NOTIFY_DONE;
> > > + }
> > > +
> > > + queue_work(mvsw_owq, _work->work);
> >
> > Once you defer the operation you cannot return an error, which is
> > problematic. Do you have a way to know if the operation will succeed or
> > not? That is, if the hardware has enough space for this new FDB entry?
> >
> Right, fdb configuration on via fw is blocking operation I still need to
> think on it if it is possible by current design.
>
>
> >
> > Why do you need both 'struct mvsw_pr_switchdev' and 'struct
> > mvsw_pr_bridge'? I think the second is enough. Also, I assume
> > 'switchdev' naming is inspired by mlxsw, but 'bridge' is better.
> >
> I changed to use bridge for bridge object, because having bridge_device
> may confuse.
>
> Thank you for your comments they were very useful, sorry for so late
> answer, I decided to re-implement this version a bit. Regarding flooding
> and default vid I still need to check it.
>
> Regards,
> Vadym Kochan
[PATCH v1 5/5] [media] mtk-mdp: Remove mtk_mdp_comp.id and supporting functionality
Since components are registered in a list, the numeric component id that
specified a location in an array is not necessary.
Signed-off-by: ei...@chromium.org
Signed-off-by: Eizan Miyamoto
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 60 +++
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 19 +-
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 10 +---
3 files changed, 11 insertions(+), 78 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index d4afed1363d5..362fff924aef 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -14,46 +14,6 @@
#include "mtk_mdp_comp.h"
-static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = {
- "mdp_rdma",
- "mdp_rsz",
- "mdp_wdma",
- "mdp_wrot",
-};
-
-struct mtk_mdp_comp_match {
- enum mtk_mdp_comp_type type;
- int alias_id;
-};
-
-static const struct mtk_mdp_comp_match mtk_mdp_matches[MTK_MDP_COMP_ID_MAX] = {
- { MTK_MDP_RDMA, 0 },
- { MTK_MDP_RDMA, 1 },
- { MTK_MDP_RSZ, 0 },
- { MTK_MDP_RSZ, 1 },
- { MTK_MDP_RSZ, 2 },
- { MTK_MDP_WDMA, 0 },
- { MTK_MDP_WROT, 0 },
- { MTK_MDP_WROT, 1 },
-};
-
-int mtk_mdp_comp_get_id(struct device *dev, struct device_node *node,
- enum mtk_mdp_comp_type comp_type)
-{
- int id = of_alias_get_id(node, mtk_mdp_comp_stem[comp_type]);
- int i;
-
- for (i = 0; i < ARRAY_SIZE(mtk_mdp_matches); i++) {
- if (comp_type == mtk_mdp_matches[i].type &&
- id == mtk_mdp_matches[i].alias_id)
- return i;
- }
-
- dev_err(dev, "Failed to get id. type: %d, id: %d\n", comp_type, id);
-
- return -EINVAL;
-}
-
void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
{
int i, err;
@@ -62,8 +22,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
mtk_mdp_comp *comp)
err = mtk_smi_larb_get(comp->larb_dev);
if (err)
dev_err(dev,
- "failed to get larb, err %d. type:%d id:%d\n",
- err, comp->type, comp->id);
+ "failed to get larb, err %d. type:%d\n",
+ err, comp->type);
}
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
@@ -72,8 +32,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
mtk_mdp_comp *comp)
err = clk_prepare_enable(comp->clk[i]);
if (err)
dev_err(dev,
- "failed to enable clock, err %d. type:%d id:%d i:%d\n",
- err, comp->type, comp->id, i);
+ "failed to enable clock, err %d. type:%d i:%d\n",
+ err, comp->type, i);
}
}
@@ -92,21 +52,15 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
mtk_mdp_comp *comp)
}
int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
- struct mtk_mdp_comp *comp, enum mtk_mdp_comp_id comp_id)
+ struct mtk_mdp_comp *comp,
+ enum mtk_mdp_comp_type comp_type)
{
struct device_node *larb_node;
struct platform_device *larb_pdev;
int i;
- if (comp_id < 0 || comp_id >= MTK_MDP_COMP_ID_MAX) {
- dev_err(dev, "Invalid comp_id %d\n", comp_id);
- return -EINVAL;
- }
-
- INIT_LIST_HEAD(>node);
comp->dev_node = of_node_get(node);
- comp->id = comp_id;
- comp->type = mtk_mdp_matches[comp_id].type;
+ comp->type = comp_type;
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
comp->clk[i] = of_clk_get(node, i);
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 1f745891c6c3..1bf0242cce46 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -22,18 +22,6 @@ enum mtk_mdp_comp_type {
MTK_MDP_COMP_TYPE_MAX,
};
-enum mtk_mdp_comp_id {
- MTK_MDP_COMP_RDMA0,
- MTK_MDP_COMP_RDMA1,
- MTK_MDP_COMP_RSZ0,
- MTK_MDP_COMP_RSZ1,
- MTK_MDP_COMP_RSZ2,
- MTK_MDP_COMP_WDMA,
- MTK_MDP_COMP_WROT0,
- MTK_MDP_COMP_WROT1,
- MTK_MDP_COMP_ID_MAX,
-};
-
/**
* struct mtk_mdp_comp - the MDP's function component data
* @node: list node to track sibing MDP components
@@ -41,7 +29,6 @@ enum mtk_mdp_comp_id {
* @clk: clocks required for component
* @larb_dev: SMI device required for component
* @type: component type
- * @id:component ID
*/
struct mtk_mdp_comp {
struct list_headnode;
@@ -49,14 +36,12 @@ struct mtk_mdp_comp {
struct clk *clk[2];
[PATCH v1 4/5] [media] mtk-mdp: convert mtk_mdp_dev.comp array to list
The functions mtk_mdp_register/unregister_component have been created to
add / remove items from the list of components.
This will eventually enable us to specify a list of components in the
device tree instead of hardcoding them into this driver.
The list is modified by a single thread at driver probe time, and will
not be traversed by another thread until the call to pm_runtime_enable
at the end of probing.
Signed-off-by: ei...@chromium.org
Signed-off-by: Eizan Miyamoto
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 1 +
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 +
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 46 +--
drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 10 +++-
4 files changed, 43 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index facc6104b91f..d4afed1363d5 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -103,6 +103,7 @@ int mtk_mdp_comp_init(struct device *dev, struct
device_node *node,
return -EINVAL;
}
+ INIT_LIST_HEAD(>node);
comp->dev_node = of_node_get(node);
comp->id = comp_id;
comp->type = mtk_mdp_matches[comp_id].type;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 3b83bd6e0d8b..1f745891c6c3 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -36,6 +36,7 @@ enum mtk_mdp_comp_id {
/**
* struct mtk_mdp_comp - the MDP's function component data
+ * @node: list node to track sibing MDP components
* @dev_node: component device node
* @clk: clocks required for component
* @larb_dev: SMI device required for component
@@ -43,6 +44,7 @@ enum mtk_mdp_comp_id {
* @id:component ID
*/
struct mtk_mdp_comp {
+ struct list_headnode;
struct device_node *dev_node;
struct clk *clk[2];
struct device *larb_dev;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index f974242663dc..e6e702d9cb69 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -55,19 +55,19 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_of_ids);
static void mtk_mdp_clock_on(struct mtk_mdp_dev *mdp)
{
struct device *dev = >pdev->dev;
- int i;
+ struct mtk_mdp_comp *comp_node;
- for (i = 0; i < ARRAY_SIZE(mdp->comp); i++)
- mtk_mdp_comp_clock_on(dev, mdp->comp[i]);
+ list_for_each_entry(comp_node, >comp_list, node)
+ mtk_mdp_comp_clock_on(dev, comp_node);
}
static void mtk_mdp_clock_off(struct mtk_mdp_dev *mdp)
{
struct device *dev = >pdev->dev;
- int i;
+ struct mtk_mdp_comp *comp_node;
- for (i = 0; i < ARRAY_SIZE(mdp->comp); i++)
- mtk_mdp_comp_clock_off(dev, mdp->comp[i]);
+ list_for_each_entry(comp_node, >comp_list, node)
+ mtk_mdp_comp_clock_off(dev, comp_node);
}
static void mtk_mdp_wdt_worker(struct work_struct *work)
@@ -91,12 +91,25 @@ static void mtk_mdp_reset_handler(void *priv)
queue_work(mdp->wdt_wq, >wdt_work);
}
+void mtk_mdp_register_component(struct mtk_mdp_dev *mdp,
+ struct mtk_mdp_comp *comp)
+{
+ list_add(>comp_list, >node);
+}
+
+void mtk_mdp_unregister_component(struct mtk_mdp_dev *mdp,
+ struct mtk_mdp_comp *comp)
+{
+ list_del(>node);
+}
+
static int mtk_mdp_probe(struct platform_device *pdev)
{
struct mtk_mdp_dev *mdp;
struct device *dev = >dev;
struct device_node *node, *parent;
- int i, ret = 0;
+ struct mtk_mdp_comp *comp, *comp_temp;
+ int ret = 0;
mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
if (!mdp)
@@ -104,6 +117,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mdp->id = pdev->id;
mdp->pdev = pdev;
+ INIT_LIST_HEAD(>comp_list);
INIT_LIST_HEAD(>ctx_list);
mutex_init(>lock);
@@ -124,7 +138,6 @@ static int mtk_mdp_probe(struct platform_device *pdev)
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;
- struct mtk_mdp_comp *comp;
of_id = of_match_node(mtk_mdp_comp_dt_ids, node);
if (!of_id)
@@ -150,13 +163,14 @@ static int mtk_mdp_probe(struct platform_device *pdev)
of_node_put(node);
goto err_comp;
}
- mdp->comp[comp_id] = comp;
ret = mtk_mdp_comp_init(dev, node, comp, comp_id);
if (ret) {
of_node_put(node);
[PATCH v2] igb: Report speed and duplex as unknown when device is runtime suspended
igb device gets runtime suspended when there's no link partner. We can't
get correct speed under that state:
$ cat /sys/class/net/enp3s0/speed
1000
In addition to that, an error can also be spotted in dmesg:
[ 385.991957] igb :03:00.0 enp3s0: PCIe link lost
Since device can only be runtime suspended when there's no link partner,
we can skip reading register and let the following logic set speed and
duplex with correct status.
The more generic approach will be wrap get_link_ksettings() with begin()
and complete() callbacks. However, for this particular issue, begin()
calls igb_runtime_resume() , which tries to rtnl_lock() while the lock
is already hold by upper ethtool layer.
So let's take this approach until the igb_runtime_resume() no longer
needs to hold rtnl_lock.
Cc: Jeff Kirsher
Cc: Aaron Brown
Suggested-by: Alexander Duyck
Signed-off-by: Kai-Heng Feng
---
v2:
- Don't early return the routine so other info can be set.
drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c
b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 39d3b76a6f5d..2cd003c5ad43 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -143,7 +143,8 @@ static int igb_get_link_ksettings(struct net_device *netdev,
u32 speed;
u32 supported, advertising;
- status = rd32(E1000_STATUS);
+ status = pm_runtime_suspended(>pdev->dev) ?
+0 : rd32(E1000_STATUS);
if (hw->phy.media_type == e1000_media_type_copper) {
supported = (SUPPORTED_10baseT_Half |
--
2.17.1
[PATCH v1 0/5] MTK MDP driver cleanups to prep for futher work
From: Eizan Miyamoto It most notably converts an array of MDP components to a list instead, but also removes some unused fields. This series of patches does some cleanup in preparation for futher work so that hardware video decode works on 4.19 and later kernels. We are planning on adding a dummy driver for the relevant MDP components that will be bound together using the component framework, which will enable calls to set up IOMMUs and LARBs, and make calls into pm_runtime. Eizan Miyamoto (5): [media] mtk-mdp: remove mtk_mdp_comp.regs from mtk_mdp_comp.h [media] mtk-mdp: handle vb2_dma_contig_set_max_seg_size errors during probe [media] mtk-mdp: handle vpu_wdt_reg_handler() errors during probe [media] mtk-mdp: convert mtk_mdp_dev.comp array to list [media] mtk-mdp: Remove mtk_mdp_comp.id and supporting functionality drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 60 ++- drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 23 +- drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 74 --- drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 10 ++- 4 files changed, 68 insertions(+), 99 deletions(-) -- 2.26.2.526.g744177e7f7-goog
[PATCH v1 2/5] [media] mtk-mdp: handle vb2_dma_contig_set_max_seg_size errors during probe
This is a cleanup to better handle errors during MDP probe.
Signed-off-by: ei...@chromium.org
Signed-off-by: Eizan Miyamoto
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index aeaed2cf4458..c20ac7681c6f 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -193,13 +193,19 @@ static int mtk_mdp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mdp);
- vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
+ ret = vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(>dev, "Failed to set vb2 dma mag seg size\n");
+ goto err_set_max_seg_size;
+ }
pm_runtime_enable(dev);
dev_dbg(dev, "mdp-%d registered successfully\n", mdp->id);
return 0;
+err_set_max_seg_size:
+
err_m2m_register:
v4l2_device_unregister(>v4l2_dev);
--
2.26.2.526.g744177e7f7-goog
[PATCH v1 1/5] [media] mtk-mdp: remove mtk_mdp_comp.regs from mtk_mdp_comp.h
These fields are not used and can be removed.
Signed-off-by: ei...@chromium.org
Signed-off-by: Eizan Miyamoto
---
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 1 -
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index 14991685adb7..facc6104b91f 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -106,7 +106,6 @@ int mtk_mdp_comp_init(struct device *dev, struct
device_node *node,
comp->dev_node = of_node_get(node);
comp->id = comp_id;
comp->type = mtk_mdp_matches[comp_id].type;
- comp->regs = of_iomap(node, 0);
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
comp->clk[i] = of_clk_get(node, i);
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 998a4b953025..3b83bd6e0d8b 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -38,7 +38,6 @@ enum mtk_mdp_comp_id {
* struct mtk_mdp_comp - the MDP's function component data
* @dev_node: component device node
* @clk: clocks required for component
- * @regs: Mapped address of component registers.
* @larb_dev: SMI device required for component
* @type: component type
* @id:component ID
@@ -46,7 +45,6 @@ enum mtk_mdp_comp_id {
struct mtk_mdp_comp {
struct device_node *dev_node;
struct clk *clk[2];
- void __iomem*regs;
struct device *larb_dev;
enum mtk_mdp_comp_type type;
enum mtk_mdp_comp_idid;
--
2.26.2.526.g744177e7f7-goog
Re: [PATCH 2/2] dt-bindings: media: Document MSM8939 Venus
On Fri, 1 May 2020 22:35:03 +0200, Konrad Dybcio wrote: > Signed-off-by: Konrad Dybcio > --- > .../bindings/media/qcom,msm8939-venus.yaml| 119 ++ > 1 file changed, 119 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/qcom,msm8939-venus.yaml > My bot found errors running 'make dt_binding_check' on your patch: Documentation/devicetree/bindings/media/qcom,msm8939-venus.example.dts:20:18: fatal error: dt-bindings/clock/qcom,gcc-msm8939.h: No such file or directory #include ^~ compilation terminated. scripts/Makefile.lib:312: recipe for target 'Documentation/devicetree/bindings/media/qcom,msm8939-venus.example.dt.yaml' failed make[1]: *** [Documentation/devicetree/bindings/media/qcom,msm8939-venus.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs Makefile:1300: recipe for target 'dt_binding_check' failed make: *** [dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1281452 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit.
Re: [PATCH v3 00/12] Convert some DT documentation files to ReST
On Wed, Apr 15, 2020 at 9:45 AM Mauro Carvalho Chehab wrote: > > While most of the devicetree stuff has its own format (with is now being > converted to YAML format), some documents there are actually > describing the DT concepts and how to contribute to it. > > IMHO, those documents would fit perfectly as part of the documentation > body, as part of the firmare documents set. > > This patch series manually converts some DT documents that, on my > opinion, would belong to it. > > If you want to see how this would show at the documentation body, > a sneak peak of this series (together with the other pending > doc patches from me) is available at: > > https://www.infradead.org/~mchehab/kernel_docs/devicetree/index.html > > - > > v3: >- rebased on the top of next-20200414 > > Mauro Carvalho Chehab (12): > docs: dt: add an index.rst file for devicetree > docs: dt: convert usage-model.txt to ReST > docs: dt: usage_model.rst: fix link for DT usage > docs: dt: convert booting-without-of.txt to ReST format > docs: dt: convert changesets to ReST > docs: dt: convert dynamic-resolution-notes.txt to ReST > docs: dt: convert of_unittest.txt to ReST > docs: dt: convert overlay-notes.txt to ReST format > docs: dt: minor adjustments at writing-schema.rst > docs: dt: convert ABI.txt to ReST format > docs: dt: convert submitting-patches.txt to ReST format > docs: dt: convert writing-bindings.txt to ReST I've applied all but patch 4 as I'm working on just removing it. Rob
Re: [PATCH v7 6/7] OPP: Update the bandwidth on OPP frequency changes
On 04-05-20, 14:01, Saravana Kannan wrote: > Fair enough. But don't "voltage corner" based devices NEED to use OPP > framework to set their frequencies? No. Anyone can call dev_pm_genpd_set_performance_state(). -- viresh
Re: [PATCH net v1] net: broadcom: fix a mistake about ioremap resource
On 5/4/2020 7:03 PM, Dejin Zheng wrote:
> Commit d7a5502b0bb8b ("net: broadcom: convert to
> devm_platform_ioremap_resource_byname()") will broke this driver.
> idm_base and nicpm_base were optional, after this change, they are
> mandatory. it will probe fails with -22 when the dtb doesn't have them
> defined. so revert part of this commit and make idm_base and nicpm_base
> as optional.
>
> Fixes: d7a5502b0bb8bde ("net: broadcom: convert to
> devm_platform_ioremap_resource_byname()")
> Reported-by: Jonathan Richardson
> Cc: Scott Branden
> Cc: Ray Jui
> Cc: Florian Fainelli
> Cc: David S. Miller
> Signed-off-by: Dejin Zheng
Acked-by: Florian Fainelli
--
Florian
Re: [f2fs-dev] [PATCH] f2fs: remove redundant check in f2fs_force_buffered_io
On 05/05, Chao Yu wrote: > On 2020-5-4 22:35, Jaegeuk Kim wrote: > > From: Daeho Jeong > > > > We already checked whether the file is compressed or not in > > f2fs_post_read_required(). So removed f2fs_compressed_file() > > in f2fs_force_buffered_io(). > > Agreed, since I have sent similar patch before: > > https://lkml.org/lkml/2020/3/24/1819 Heh, as I couldn't find yours, I was actually waiting for you to point out. :) > > Just want to know what's the change of backport concern now. Old ICE support had to decouple f2fs_post_read_required() and f2fs_forced_buffered_io(). Now, I decide to manage this as we need to manage this for one kernel version only. Thanks, > > Thanks, > > > > > Signed-off-by: Daeho Jeong > > Signed-off-by: Jaegeuk Kim > > --- > > fs/f2fs/f2fs.h | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h > > index 6b7b963641696..01a00fc808361 100644 > > --- a/fs/f2fs/f2fs.h > > +++ b/fs/f2fs/f2fs.h > > @@ -4064,8 +4064,6 @@ static inline bool f2fs_force_buffered_io(struct > > inode *inode, > > return true; > > if (f2fs_is_multi_device(sbi)) > > return true; > > - if (f2fs_compressed_file(inode)) > > - return true; > > /* > > * for blkzoned device, fallback direct IO to buffered IO, so > > * all IOs can be serialized by log-structured write. > >
[PATCH v6 0/2] Add a watchdog driver that uses ARM Secure Monitor Calls.
This is currently supported in firmware deployed on oak, hana and elm mt8173 chromebook devices. The kernel driver is written to be a generic SMC watchdog driver. Arm Trusted Firmware upstreaming review: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3405 Patch to add oak, hana, elm device tree: https://lore.kernel.org/linux-arm-kernel/20200110073730.213789-1-hsi...@chromium.org/ I would like to add the device tree support after the above patch is accepted. Changes in v6: - Don't use dt default - Use default arm,smc-id value if non provided by dt Changes in v5: - Change compatible to arm,smc-wdt - Make timeleft return 0 on error - Use type punning on smc_func_id to save an alloc - Change compatible to arm,smc-wdt Changes in v4: - Add arm,smc-id property - Get smc-id from of property - Return a1 instead of a0 in timeleft Changes in v3: - Change name back to arm - Add optional get_timeleft op - change name to arm_smc_wdt Changes in v2: - Change name arm > mt8173 - use watchdog_stop_on_reboot - use watchdog_stop_on_unregister - use devm_watchdog_register_device - remove smcwd_shutdown, smcwd_remove - change error codes Evan Benn (1): dt-bindings: watchdog: Add ARM smc wdt for mt8173 watchdog Julius Werner (1): watchdog: Add new arm_smc_wdt watchdog driver .../bindings/watchdog/arm-smc-wdt.yaml| 37 MAINTAINERS | 7 + arch/arm64/configs/defconfig | 1 + drivers/watchdog/Kconfig | 13 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/arm_smc_wdt.c| 188 ++ 6 files changed, 247 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml create mode 100644 drivers/watchdog/arm_smc_wdt.c -- 2.26.2.526.g744177e7f7-goog
[PATCH v6 2/2] watchdog: Add new arm_smc_wdt watchdog driver
From: Julius Werner
This patch adds a watchdog driver that can be used on ARM systems
with the appropriate watchdog implemented in Secure Monitor firmware.
The driver communicates with firmware via a Secure Monitor Call.
This may be useful for platforms using TrustZone that want
the Secure Monitor firmware to have the final control over the watchdog.
This is implemented on mt8173 chromebook devices oak, elm and hana in
arm trusted firmware file plat/mediatek/mt8173/drivers/wdt/wdt.c.
Signed-off-by: Julius Werner
Signed-off-by: Evan Benn
---
Changes in v6:
- Use default arm,smc-id value if non provided by dt
Changes in v5:
- Make timeleft return 0 on error
- Use type punning on smc_func_id to save an alloc
- Change compatible to arm,smc-wdt
Changes in v4:
- Get smc-id from of property
- Return a1 instead of a0 in timeleft
Changes in v3:
- Add optional get_timeleft op
- change name to arm_smc_wdt
Changes in v2:
- use watchdog_stop_on_reboot
- use watchdog_stop_on_unregister
- use devm_watchdog_register_device
- remove smcwd_shutdown, smcwd_remove
- change error codes
MAINTAINERS| 1 +
arch/arm64/configs/defconfig | 1 +
drivers/watchdog/Kconfig | 13 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/arm_smc_wdt.c | 188 +
5 files changed, 204 insertions(+)
create mode 100644 drivers/watchdog/arm_smc_wdt.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 0f2b39767bfa9..2b782bbff200a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1462,6 +1462,7 @@ M:Julius Werner
R: Evan Benn
S: Maintained
F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
+F: drivers/watchdog/arm_smc_wdt.c
ARM SMMU DRIVERS
M: Will Deacon
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 24e534d850454..0619df80f7575 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -513,6 +513,7 @@ CONFIG_UNIPHIER_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_ARM_SBSA_WATCHDOG=y
+CONFIG_ARM_SMC_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_DW_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=m
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 0663c604bd642..c440b576d23bf 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -867,6 +867,19 @@ config DIGICOLOR_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called digicolor_wdt.
+config ARM_SMC_WATCHDOG
+ tristate "ARM Secure Monitor Call based watchdog support"
+ depends on ARM || ARM64
+ depends on OF
+ depends on HAVE_ARM_SMCCC
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for a watchdog timer
+ implemented by the EL3 Secure Monitor on ARM platforms.
+ Requires firmware support.
+ To compile this driver as a module, choose M here: the
+ module will be called arm_smc_wdt.
+
config LPC18XX_WATCHDOG
tristate "LPC18xx/43xx Watchdog"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 6de2e4ceef190..97bed1d3d97cb 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_UNIPHIER_WATCHDOG) += uniphier_wdt.o
obj-$(CONFIG_RTD119X_WATCHDOG) += rtd119x_wdt.o
obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
obj-$(CONFIG_PM8916_WATCHDOG) += pm8916_wdt.o
+obj-$(CONFIG_ARM_SMC_WATCHDOG) += arm_smc_wdt.o
# X86 (i386 + ia64 + x86_64) Architecture
obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o
diff --git a/drivers/watchdog/arm_smc_wdt.c b/drivers/watchdog/arm_smc_wdt.c
new file mode 100644
index 0..8f3d0c3a005fb
--- /dev/null
+++ b/drivers/watchdog/arm_smc_wdt.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ARM Secure Monitor Call watchdog driver
+ *
+ * Copyright 2020 Google LLC.
+ * Julius Werner
+ * Based on mtk_wdt.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "arm_smc_wdt"
+#define DRV_VERSION"1.0"
+
+enum smcwd_call {
+ SMCWD_INIT = 0,
+ SMCWD_SET_TIMEOUT = 1,
+ SMCWD_ENABLE= 2,
+ SMCWD_PET = 3,
+ SMCWD_GET_TIMELEFT = 4,
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static unsigned int timeout;
+
+static int smcwd_call(struct watchdog_device *wdd, enum smcwd_call call,
+ unsigned long arg, struct arm_smccc_res *res)
+{
+ struct arm_smccc_res local_res;
+
+ if (!res)
+ res = _res;
+
+ arm_smccc_smc((u32)(uintptr_t)watchdog_get_drvdata(wdd), call, arg, 0,
+ 0, 0, 0, 0, res);
+
+ if (res->a0 == PSCI_RET_NOT_SUPPORTED)
+ return -ENODEV;
+ if (res->a0 == PSCI_RET_INVALID_PARAMS)
+ return -EINVAL;
+ if
[PATCH v6 1/2] dt-bindings: watchdog: Add ARM smc wdt for mt8173 watchdog
This watchdog can be used on ARM systems with a Secure
Monitor firmware to forward watchdog operations to
firmware via a Secure Monitor Call.
Signed-off-by: Evan Benn
---
Changes in v6:
- Don't use dt default
Changes in v5:
- Change compatible to arm,smc-wdt
Changes in v4:
- Add arm,smc-id property
Changes in v3:
- Change name back to arm
Changes in v2:
- Change name arm > mt8173
.../bindings/watchdog/arm-smc-wdt.yaml| 37 +++
MAINTAINERS | 6 +++
2 files changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
b/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
new file mode 100644
index 0..bec651541e0c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/arm-smc-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Secure Monitor Call based watchdog
+
+allOf:
+ - $ref: "watchdog.yaml#"
+
+maintainers:
+ - Julius Werner
+
+properties:
+ compatible:
+enum:
+ - arm,smc-wdt
+ arm,smc-id:
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+description: |
+ The ATF smc function id used by the firmware.
+ Defaults to 0x82003D06 if unset.
+
+required:
+ - compatible
+
+examples:
+ - |
+watchdog {
+ compatible = "arm,smc-wdt";
+ arm,smc-id = <0x82003D06>;
+ timeout-sec = <15>;
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index b816a453b10eb..0f2b39767bfa9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1457,6 +1457,12 @@ S: Maintained
F: Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt
F: drivers/irqchip/irq-vic.c
+ARM SMC WATCHDOG DRIVER
+M: Julius Werner
+R: Evan Benn
+S: Maintained
+F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
+
ARM SMMU DRIVERS
M: Will Deacon
R: Robin Murphy
--
2.26.2.526.g744177e7f7-goog
Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper
On Mon, May 4, 2020 at 10:52 PM Pavel Tatashin
wrote:
>
> > > @@ -3157,12 +3162,9 @@ void kmsg_dump(enum kmsg_dump_reason reason)
> > > struct kmsg_dumper *dumper;
> > > unsigned long flags;
> > >
> > > - if ((reason > KMSG_DUMP_OOPS) && !always_kmsg_dump)
> > > - return;
> > > -
> > > rcu_read_lock();
> > > list_for_each_entry_rcu(dumper, _list, list) {
> > > - if (dumper->max_reason && reason > dumper->max_reason)
> > > + if (reason > dumper->max_reason)
> > > continue;
> >
> > Why always_kmsg_dump check moved from the dumper loop entry point to the
> > dumper registration code? What if the user change always_ksmsg_dump
> > dynamically via sysfs?
>
> Hi Sergey,
>
> I changed it to make code cleaner: for such basic operation there are
> too many conditions if we will keep it inside the kmsg_dump().
> However, if being able to set always_kmsg_dump dynamically during
> runtime is deemed important, I can change it back to be checked in
> kmsg_dump.
If you agree that we do not have to modify this variable dynamically,
I will also change the permission here:
module_param_named(always_kmsg_dump, always_kmsg_dump, bool, S_IRUGO | S_IWUSR);
>
> Thank you,
> Pasha
>
> >
> > -ss
Re: [PATCH v8 4/4] kvm: vmx: virtualize split lock detection
On Wed, Apr 15, 2020 at 02:43:18PM -0700, Sean Christopherson wrote:
> On Wed, Apr 15, 2020 at 11:22:11PM +0200, Thomas Gleixner wrote:
> > Sean Christopherson writes:
> > > I don't see any way to avoid having KVM differentiate between sld_warn and
> > > sld_fatal. Even if KVM is able to virtualize SLD in sld_fatal mode, e.g.
> > > by telling the guest it must not try to disable SLD, KVM would still need
> > > to know the kernel is sld_fatal so that it can forward that information to
> > > the guest.
> >
> > Huch? There is absolutely zero code like that. The only place where
> > sld_state is used is:
> >
> > + static inline void vmx_update_sld(struct kvm_vcpu *vcpu, bool on)
> > + {
> > + if (sld_state == sld_warn && guest_cpu_has_feature_sld(vcpu) &&
> > + on == test_thread_flag(TIF_SLD)) {
> > + sld_update_msr(on);
> > + update_thread_flag(TIF_SLD, !on);
> > + }
> >
> > You might have some faint memories from the previous trainwrecks :)
>
> Yeah, I was thinking SLD was only being exposed if the host is sld_warn.
> I'll work with Xiaoyao to figure out a cleaner interface for this code.
...
> > So we can go with the proposed mode of allowing the write but not
> > propagating it. If the resulting split lock #AC originates from CPL != 3
> > then the guest will be killed with SIGBUS. If it originates from CPL ==
> > 3 and the guest has user #AC disabled then it will be killed as well.
>
> An idea that's been floated around to avoid killing the guest on a CPL==3
> split-lock #AC is to add a STICKY bit to MSR_TEST_CTRL that KVM can
> virtualize to tell the guest that attempting to disable SLD is futile,
> e.g. so that the guest can kill its misbehaving userspace apps instead of
> trying to disable SLD and getting killed by the host.
Circling back to this. KVM needs access to sld_state in one form or another
if we want to add a KVM hint when the host is in fatal mode. Three options
I've come up with:
1. Bite the bullet and export sld_state.
2. Add an is_split_fatal_wrapper(). Ugly since it needs to be non-inline
to avoid triggering (1).
3. Add a synthetic feature flag, e.g. X86_FEATURE_SLD_FATAL, and drop
sld_state altogether.
I like (3) because it requires the least amount of code when all is said
and done, doesn't require more exports, and as a bonus it'd probably be nice
for userspace to see sld_fatal in /proc/cpuinfo.
Thoughts?
Re: [PATCH 2/2] scripts/dtc: compile separate dtc-yaml
On Tue, May 5, 2020 at 4:15 AM Rob Herring wrote: > > On Sun, May 3, 2020 at 9:07 PM Masahiro Yamada wrote: > > > > Marek Behún reported a case where pkg-config fails to detect the > > libyaml-dev package, which is presumably a bug of the distro. > > > > Irrespective of that, I am not a big fan of pkg-config in the Makefile > > parse stage. The cost of pkg-config is quite small, but it is evaluated > > everytime we run make, even when we do 'make mrproper'. This commit > > changes the Makefile to not rely on pkg-config at all. > > I don't really love the solution here... I'm inclined to just make > libyaml always required. Anyone building dtbs should care about > validating them. However, there's some dts files sprinkled in the tree > such as DT unittests and I don't want to break allmodconfig for CI, > 0-day, etc. Though eventually we may have to. > > > The normal build should not require libyaml-dev while we need to compile > > dtc with libyaml for the schema check. > > > > Build two dtc variants: > > > > scripts/dtc/dtc for *.dts -> *.dtb > > scripts/dtc/dtc-yaml for *.dts -> *.dt.yaml > > My longer term plan is to integrate the schema checks into dtc. This > would be some sort of plugin to dtc found or specified at run-time. It > would eliminate the need for 2 passes of dtc and the 2nd case will go > away. OK. > > --- a/scripts/Makefile.lib > > +++ b/scripts/Makefile.lib > > @@ -246,6 +246,7 @@ quiet_cmd_gzip = GZIP$@ > > # DTC > > # > > --- > > DTC ?= $(objtree)/scripts/dtc/dtc > > +DTC_YAML ?= $(objtree)/scripts/dtc/dtc-yaml > > Can we make 'DTC' override both and keep this an internal detail. > No. For parallel building *.dtb and *.dt.yaml, they must be separate instances. > > +HOSTLDLIBS_dtc-yaml := -lyaml > > Does this work for yocto? As we had this before commit 067c650c456e. > Not clear if this changed for any reason or just 'let's use pkg-config > everywhere'. > > Or is there another way to fix yocto issue and we can just check the > header exists. I assume yocto needs some prefix in front of > '/usr/include/yaml.h'? > My bad - I missed 067c650c456e We need pkg-config to deal with yocto. Sorry, I take back this series. -- Best Regards Masahiro Yamada
[PATCH 1/2] ALSA: hda: Use dev_to_hdac_dev macro
Use dev_to_hdac_dev() instead of container_of().
No functional change intended.
Signed-off-by: Kai-Heng Feng
---
sound/hda/ext/hdac_ext_bus.c | 2 +-
sound/hda/hdac_device.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/hda/ext/hdac_ext_bus.c b/sound/hda/ext/hdac_ext_bus.c
index 73bfa71845f6..d0a604c939df 100644
--- a/sound/hda/ext/hdac_ext_bus.c
+++ b/sound/hda/ext/hdac_ext_bus.c
@@ -62,7 +62,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_exit);
static void default_release(struct device *dev)
{
- snd_hdac_ext_bus_device_exit(container_of(dev, struct hdac_device,
dev));
+ snd_hdac_ext_bus_device_exit(dev_to_hdac_dev(dev));
}
/**
diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c
index e3119f5cb0d5..333220f0f8af 100644
--- a/sound/hda/hdac_device.c
+++ b/sound/hda/hdac_device.c
@@ -20,7 +20,7 @@ static int get_codec_vendor_name(struct hdac_device *codec);
static void default_release(struct device *dev)
{
- snd_hdac_device_exit(container_of(dev, struct hdac_device, dev));
+ snd_hdac_device_exit(dev_to_hdac_dev(dev));
}
/**
--
2.17.1
[PATCH 2/2] ALSA: hda: Use hdac_to_hda_codec macro
Use hdac_to_hda_codec() instead of container_of().
No functional change intended.
Signed-off-by: Kai-Heng Feng
---
include/sound/hda_codec.h | 4
sound/pci/hda/patch_hdmi.c | 12 ++--
sound/soc/codecs/hdac_hda.h | 4
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/sound/hda_codec.h b/include/sound/hda_codec.h
index 225154a4f2ed..8a32060e3d8d 100644
--- a/include/sound/hda_codec.h
+++ b/include/sound/hda_codec.h
@@ -288,6 +288,10 @@ struct hda_codec {
#define dev_to_hda_codec(_dev) container_of(_dev, struct hda_codec, core.dev)
#define hda_codec_dev(_dev)(&(_dev)->core.dev)
+#define hdac_to_hda_priv(_hdac) \
+ container_of(_hdac, struct hdac_hda_priv, codec.core)
+#define hdac_to_hda_codec(_hdac) container_of(_hdac, struct hda_codec, core)
+
#define list_for_each_codec(c, bus) \
list_for_each_entry(c, &(bus)->core.codec_list, core.list)
#define list_for_each_codec_safe(c, n, bus)\
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 4eff16053bd5..f21b66abb271 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2022,7 +2022,7 @@ static const struct hda_pcm_ops generic_ops = {
static int hdmi_get_spk_alloc(struct hdac_device *hdac, int pcm_idx)
{
- struct hda_codec *codec = container_of(hdac, struct hda_codec, core);
+ struct hda_codec *codec = hdac_to_hda_codec(hdac);
struct hdmi_spec *spec = codec->spec;
struct hdmi_spec_per_pin *per_pin = pcm_idx_to_pin(spec, pcm_idx);
@@ -2035,7 +2035,7 @@ static int hdmi_get_spk_alloc(struct hdac_device *hdac,
int pcm_idx)
static void hdmi_get_chmap(struct hdac_device *hdac, int pcm_idx,
unsigned char *chmap)
{
- struct hda_codec *codec = container_of(hdac, struct hda_codec, core);
+ struct hda_codec *codec = hdac_to_hda_codec(hdac);
struct hdmi_spec *spec = codec->spec;
struct hdmi_spec_per_pin *per_pin = pcm_idx_to_pin(spec, pcm_idx);
@@ -2049,7 +2049,7 @@ static void hdmi_get_chmap(struct hdac_device *hdac, int
pcm_idx,
static void hdmi_set_chmap(struct hdac_device *hdac, int pcm_idx,
unsigned char *chmap, int prepared)
{
- struct hda_codec *codec = container_of(hdac, struct hda_codec, core);
+ struct hda_codec *codec = hdac_to_hda_codec(hdac);
struct hdmi_spec *spec = codec->spec;
struct hdmi_spec_per_pin *per_pin = pcm_idx_to_pin(spec, pcm_idx);
@@ -2065,7 +2065,7 @@ static void hdmi_set_chmap(struct hdac_device *hdac, int
pcm_idx,
static bool is_hdmi_pcm_attached(struct hdac_device *hdac, int pcm_idx)
{
- struct hda_codec *codec = container_of(hdac, struct hda_codec, core);
+ struct hda_codec *codec = hdac_to_hda_codec(hdac);
struct hdmi_spec *spec = codec->spec;
struct hdmi_spec_per_pin *per_pin = pcm_idx_to_pin(spec, pcm_idx);
@@ -3783,7 +3783,7 @@ static int atihdmi_paired_chmap_validate(struct
hdac_chmap *chmap,
static int atihdmi_pin_set_slot_channel(struct hdac_device *hdac,
hda_nid_t pin_nid, int hdmi_slot, int stream_channel)
{
- struct hda_codec *codec = container_of(hdac, struct hda_codec, core);
+ struct hda_codec *codec = hdac_to_hda_codec(hdac);
int verb;
int ati_channel_setup = 0;
@@ -3819,7 +3819,7 @@ static int atihdmi_pin_set_slot_channel(struct
hdac_device *hdac,
static int atihdmi_pin_get_slot_channel(struct hdac_device *hdac,
hda_nid_t pin_nid, int asp_slot)
{
- struct hda_codec *codec = container_of(hdac, struct hda_codec, core);
+ struct hda_codec *codec = hdac_to_hda_codec(hdac);
bool was_odd = false;
int ati_asp_slot = asp_slot;
int verb;
diff --git a/sound/soc/codecs/hdac_hda.h b/sound/soc/codecs/hdac_hda.h
index 598b07d9b6fe..d0efc5e254ae 100644
--- a/sound/soc/codecs/hdac_hda.h
+++ b/sound/soc/codecs/hdac_hda.h
@@ -28,10 +28,6 @@ struct hdac_hda_priv {
bool need_display_power;
};
-#define hdac_to_hda_priv(_hdac) \
- container_of(_hdac, struct hdac_hda_priv, codec.core)
-#define hdac_to_hda_codec(_hdac) container_of(_hdac, struct hda_codec, core)
-
struct hdac_ext_bus_ops *snd_soc_hdac_hda_get_ops(void);
#endif /* __HDAC_HDA_H__ */
--
2.17.1
Re: [PATCH 2/3] mfd: Intel Platform Monitoring Technology support
On 5/4/20 7:31 PM, David E. Box wrote: > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 0a59249198d3..c673031acdf1 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -632,6 +632,16 @@ config MFD_INTEL_MSIC > Passage) chip. This chip embeds audio, battery, GPIO, etc. > devices used in Intel Medfield platforms. > > +config MFD_INTEL_PMT > + tristate "Intel Platform Monitoring Technology support" > + depends on PCI > + select MFD_CORE > + help > + The Intel Platform Monitoring Technology (PMT) is an interface that > + provides access to hardware monitor registers. This driver supports > + Telemetry, Watcher, and Crashlog PTM capabilities/devices for What is PTM? > + platforms starting from Tiger Lake. > + > config MFD_IPAQ_MICRO > bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support" > depends on SA1100_H3100 || SA1100_H3600 -- ~Randy
Re: [PATCH 3/3] mm/hugetlb: Introduce HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS
On 04/26/2020 08:31 AM, Andrew Morton wrote:
> On Sun, 26 Apr 2020 08:13:17 +0530 Anshuman Khandual
> wrote:
>
>>
>>
>> On 04/26/2020 06:25 AM, Andrew Morton wrote:
>>> On Tue, 14 Apr 2020 17:14:30 +0530 Anshuman Khandual
>>> wrote:
>>>
>>>> There are multiple similar definitions for arch_clear_hugepage_flags() on
>>>> various platforms. This introduces HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS for those
>>>> platforms that need to define their own arch_clear_hugepage_flags() while
>>>> also providing a generic fallback definition for others to use. This help
>>>> reduce code duplication.
>>>>
>>>> ...
>>>>
>>>> --- a/include/linux/hugetlb.h
>>>> +++ b/include/linux/hugetlb.h
>>>> @@ -544,6 +544,10 @@ static inline int is_hugepage_only_range(struct
>>>> mm_struct *mm,
>>>> }
>>>> #endif
>>>>
>>>> +#ifndef HAVE_ARCH_CLEAR_HUGEPAGE_FLAGS
>>>> +static inline void arch_clear_hugepage_flags(struct page *page) { }
>>>> +#endif
>>>> +
>>>> #ifndef arch_make_huge_pte
>>>> static inline pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct
>>>> *vma,
>>>> struct page *page, int writable)
>>>
>>> This is the rather old-school way of doing it. The Linus-suggested way is
>>>
>>> #ifndef arch_clear_hugepage_flags
>>> static inline void arch_clear_hugepage_flags(struct page *page)
>>> {
>>> }
>>> #define arch_clear_hugepage_flags arch_clear_hugepage_flags
>>
>> Do we need that above line here ? Is not that implicit.
>
> It depends if other header files want to test whether
> arch_clear_hugepage_flags is already defined. If the header heorarchy
> is well-defined and working properly, they shouldn't need to, because
> we're reliably indluding the relevant arch header before (or early
> within) include/linux/hugetlb.h.
>
> It would be nice if
>
> #define arch_clear_hugepage_flags arch_clear_hugepage_flags
> #define arch_clear_hugepage_flags arch_clear_hugepage_flags
>
> were to generate an compiler error but it doesn't. If it did we could
> detect these incorrect inclusion orders.
>
>>> #endif
>>>
>>> And the various arch headers do
>>>
>>> static inline void arch_clear_hugepage_flags(struct page *page)
>>> {
>>>
>>> }
>>> #define arch_clear_hugepage_flags arch_clear_hugepage_flags
>>>
>>> It's a small difference - mainly to avoid adding two variables to the
>>> overall namespace where one would do.
>>
>> Understood, will change and resend.
>
> That's OK - I've queued up that fix.
>
Hello Andrew,
I might not have searched all the relevant trees or might have just searched
earlier than required. But I dont see these patches (or your proposed fixes)
either in mmotm (2020-04-29-23-04) or in next-20200504. Wondering if you are
waiting on a V2 for this series accommodating the changes you had proposed.
- Anshuman
Re: [PATCH v1 1/3] printk: honor the max_reason field in kmsg_dumper
> > @@ -3157,12 +3162,9 @@ void kmsg_dump(enum kmsg_dump_reason reason)
> > struct kmsg_dumper *dumper;
> > unsigned long flags;
> >
> > - if ((reason > KMSG_DUMP_OOPS) && !always_kmsg_dump)
> > - return;
> > -
> > rcu_read_lock();
> > list_for_each_entry_rcu(dumper, _list, list) {
> > - if (dumper->max_reason && reason > dumper->max_reason)
> > + if (reason > dumper->max_reason)
> > continue;
>
> Why always_kmsg_dump check moved from the dumper loop entry point to the
> dumper registration code? What if the user change always_ksmsg_dump
> dynamically via sysfs?
Hi Sergey,
I changed it to make code cleaner: for such basic operation there are
too many conditions if we will keep it inside the kmsg_dump().
However, if being able to set always_kmsg_dump dynamically during
runtime is deemed important, I can change it back to be checked in
kmsg_dump.
Thank you,
Pasha
>
> -ss
RE: [PATCH net-next] ixgbe: fix signed-integer-overflow warning
> -Original Message- > From: Xie XiuQi > Sent: Monday, May 4, 2020 19:45 > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH net-next] ixgbe: fix signed-integer-overflow warning > > ubsan report this warning, fix it by adding a unsigned suffix. > > UBSAN: signed-integer-overflow in > drivers/net/ethernet/intel/ixgbe/ixgbe_common.c:2246:26 > 65535 * 65537 cannot be represented in type 'int' > CPU: 21 PID: 7 Comm: kworker/u256:0 Not tainted 5.7.0-rc3-debug+ #39 > Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 > 03/27/2020 > Workqueue: ixgbe ixgbe_service_task [ixgbe] Call trace: > dump_backtrace+0x0/0x3f0 > show_stack+0x28/0x38 > dump_stack+0x154/0x1e4 > ubsan_epilogue+0x18/0x60 > handle_overflow+0xf8/0x148 > __ubsan_handle_mul_overflow+0x34/0x48 > ixgbe_fc_enable_generic+0x4d0/0x590 [ixgbe] > ixgbe_service_task+0xc20/0x1f78 [ixgbe] > process_one_work+0x8f0/0xf18 > worker_thread+0x430/0x6d0 > kthread+0x218/0x238 > ret_from_fork+0x10/0x18 > > Reported-by: Hulk Robot > Signed-off-by: Xie XiuQi > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Dave, I am picking this up.
[PATCH v5 0/8] Bug fixes and improved logging in MHI
A set of patches for bug fixes and improved logging in mhi/core/boot.c. Verified on x86 and arm64 platforms. v5: -Updated the macro MHI_RANDOM_U32_NONZERO to take a bitmask as the input parameter and output a non-zero value between 1 and U32_MAX v4: -Dropped the change: bus: mhi: core: WARN_ON for malformed vector table -Updated bus: mhi: core: Read transfer length from an event properly to include parse rsc events -Use prandom_u32_max() instead of prandom_u32 to avoid if check in bus: mhi: core: Ensure non-zero session or sequence ID values are used v3: -Fixed signed-off-by tags -Add a refactor patch for MHI queue APIs -Commit text fix in bus: mhi: core: Read transfer length from an event properly -Fix channel ID range check for ctrl and data event rings processing v2: -Fix channel ID range check potential infinite loop -Add appropriate signed-off-by tags Bhaumik Bhatt (4): bus: mhi: core: Handle firmware load using state worker bus: mhi: core: Return appropriate error codes for AMSS load failure bus: mhi: core: Improve debug logs for loading firmware bus: mhi: core: Ensure non-zero session or sequence ID values are used Hemant Kumar (4): bus: mhi: core: Refactor mhi queue APIs bus: mhi: core: Cache intmod from mhi event to mhi channel bus: mhi: core: Add range check for channel id received in event ring bus: mhi: core: Read transfer length from an event properly drivers/bus/mhi/core/boot.c | 75 drivers/bus/mhi/core/init.c | 5 +- drivers/bus/mhi/core/internal.h | 6 +- drivers/bus/mhi/core/main.c | 124 drivers/bus/mhi/core/pm.c | 6 +- include/linux/mhi.h | 2 - 6 files changed, 109 insertions(+), 109 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v5 3/8] bus: mhi: core: Add range check for channel id received in event ring
From: Hemant Kumar
MHI data completion handler function reads channel id from event
ring element. Value is under the control of MHI devices and can be
any value between 0 and 255. In order to prevent out of bound access
add a bound check against the max channel supported by controller
and skip processing of that event ring element.
Signed-off-by: Hemant Kumar
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
---
drivers/bus/mhi/core/main.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 605640c..e60ab21 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -776,6 +776,9 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
*mhi_cntrl,
case MHI_PKT_TYPE_TX_EVENT:
chan = MHI_TRE_GET_EV_CHID(local_rp);
mhi_chan = _cntrl->mhi_chan[chan];
+ if (WARN_ON(chan >= mhi_cntrl->max_chan))
+ goto next_event;
+
parse_xfer_event(mhi_cntrl, local_rp, mhi_chan);
event_quota--;
break;
@@ -784,6 +787,7 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
*mhi_cntrl,
break;
}
+next_event:
mhi_recycle_ev_ring_element(mhi_cntrl, ev_ring);
local_rp = ev_ring->rp;
dev_rp = mhi_to_virtual(ev_ring, er_ctxt->rp);
@@ -820,6 +824,9 @@ int mhi_process_data_event_ring(struct mhi_controller
*mhi_cntrl,
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
chan = MHI_TRE_GET_EV_CHID(local_rp);
+ if (WARN_ON(chan >= mhi_cntrl->max_chan))
+ goto next_event;
+
mhi_chan = _cntrl->mhi_chan[chan];
if (likely(type == MHI_PKT_TYPE_TX_EVENT)) {
@@ -830,6 +837,7 @@ int mhi_process_data_event_ring(struct mhi_controller
*mhi_cntrl,
event_quota--;
}
+next_event:
mhi_recycle_ev_ring_element(mhi_cntrl, ev_ring);
local_rp = ev_ring->rp;
dev_rp = mhi_to_virtual(ev_ring, er_ctxt->rp);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v5 8/8] bus: mhi: core: Ensure non-zero session or sequence ID values are used
While writing any sequence or session identifiers, it is possible that
the host could write a zero value, whereas only non-zero values should
be supported writes to those registers. Ensure that the host does not
write a non-zero value for them and also log them in debug messages.
Signed-off-by: Bhaumik Bhatt
---
drivers/bus/mhi/core/boot.c | 15 +++
drivers/bus/mhi/core/internal.h | 2 ++
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index e5fcde1..7b9b561 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -43,10 +43,7 @@ void mhi_rddm_prepare(struct mhi_controller *mhi_cntrl,
lower_32_bits(mhi_buf->dma_addr));
mhi_write_reg(mhi_cntrl, base, BHIE_RXVECSIZE_OFFS, mhi_buf->len);
- sequence_id = prandom_u32() & BHIE_RXVECSTATUS_SEQNUM_BMSK;
-
- if (unlikely(!sequence_id))
- sequence_id = 1;
+ sequence_id = MHI_RANDOM_U32_NONZERO(BHIE_RXVECSTATUS_SEQNUM_BMSK);
mhi_write_reg_field(mhi_cntrl, base, BHIE_RXVECDB_OFFS,
BHIE_RXVECDB_SEQNUM_BMSK, BHIE_RXVECDB_SEQNUM_SHFT,
@@ -189,7 +186,9 @@ static int mhi_fw_load_amss(struct mhi_controller
*mhi_cntrl,
return -EIO;
}
- dev_dbg(dev, "Starting AMSS download via BHIe\n");
+ sequence_id = MHI_RANDOM_U32_NONZERO(BHIE_TXVECSTATUS_SEQNUM_BMSK);
+ dev_dbg(dev, "Starting AMSS download via BHIe. Sequence ID:%u\n",
+ sequence_id);
mhi_write_reg(mhi_cntrl, base, BHIE_TXVECADDR_HIGH_OFFS,
upper_32_bits(mhi_buf->dma_addr));
@@ -198,7 +197,6 @@ static int mhi_fw_load_amss(struct mhi_controller
*mhi_cntrl,
mhi_write_reg(mhi_cntrl, base, BHIE_TXVECSIZE_OFFS, mhi_buf->len);
- sequence_id = prandom_u32() & BHIE_TXVECSTATUS_SEQNUM_BMSK;
mhi_write_reg_field(mhi_cntrl, base, BHIE_TXVECDB_OFFS,
BHIE_TXVECDB_SEQNUM_BMSK, BHIE_TXVECDB_SEQNUM_SHFT,
sequence_id);
@@ -246,14 +244,15 @@ static int mhi_fw_load_sbl(struct mhi_controller
*mhi_cntrl,
goto invalid_pm_state;
}
- dev_dbg(dev, "Starting SBL download via BHI\n");
+ session_id = MHI_RANDOM_U32_NONZERO(BHI_TXDB_SEQNUM_BMSK);
+ dev_dbg(dev, "Starting SBL download via BHI. Session ID:%u\n",
+ session_id);
mhi_write_reg(mhi_cntrl, base, BHI_STATUS, 0);
mhi_write_reg(mhi_cntrl, base, BHI_IMGADDR_HIGH,
upper_32_bits(dma_addr));
mhi_write_reg(mhi_cntrl, base, BHI_IMGADDR_LOW,
lower_32_bits(dma_addr));
mhi_write_reg(mhi_cntrl, base, BHI_IMGSIZE, size);
- session_id = prandom_u32() & BHI_TXDB_SEQNUM_BMSK;
mhi_write_reg(mhi_cntrl, base, BHI_IMGTXDB, session_id);
read_unlock_bh(pm_lock);
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 0965ca3..3205a92 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -452,6 +452,8 @@ enum mhi_pm_state {
#define PRIMARY_CMD_RING 0
#define MHI_DEV_WAKE_DB127
#define MHI_MAX_MTU0x
+#define MHI_RANDOM_U32_NONZERO(bmsk) ((prandom_u32_max(U32_MAX - 1) & \
+(bmsk)) + 1)
enum mhi_er_type {
MHI_ER_TYPE_INVALID = 0x0,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v5 1/8] bus: mhi: core: Refactor mhi queue APIs
From: Hemant Kumar
Move all the common code to generate TRE from mhi_queue_buf,
mhi_queue_dma and mhi_queue_skb to mhi_gen_tre. This helps
to centralize the TRE generation code which makes any future
bug fixing easier to manage in these APIs.
Suggested-by: Jeffrey Hugo
Signed-off-by: Hemant Kumar
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
---
drivers/bus/mhi/core/internal.h | 3 +-
drivers/bus/mhi/core/main.c | 107 +---
2 files changed, 47 insertions(+), 63 deletions(-)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 095d95b..40c47f9 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -670,8 +670,7 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
*mhi_cntrl,
irqreturn_t mhi_intvec_handler(int irq_number, void *dev);
int mhi_gen_tre(struct mhi_controller *mhi_cntrl, struct mhi_chan *mhi_chan,
- void *buf, void *cb, size_t buf_len, enum mhi_flags flags);
-
+ struct mhi_buf_info *info, enum mhi_flags flags);
int mhi_map_single_no_bb(struct mhi_controller *mhi_cntrl,
struct mhi_buf_info *buf_info);
int mhi_map_single_use_bb(struct mhi_controller *mhi_cntrl,
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index c26eed0..605640c 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -919,9 +919,7 @@ int mhi_queue_skb(struct mhi_device *mhi_dev, enum
dma_data_direction dir,
struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ? mhi_dev->ul_chan :
mhi_dev->dl_chan;
struct mhi_ring *tre_ring = _chan->tre_ring;
- struct mhi_ring *buf_ring = _chan->buf_ring;
- struct mhi_buf_info *buf_info;
- struct mhi_tre *mhi_tre;
+ struct mhi_buf_info buf_info = { };
int ret;
/* If MHI host pre-allocates buffers then client drivers cannot queue */
@@ -946,27 +944,15 @@ int mhi_queue_skb(struct mhi_device *mhi_dev, enum
dma_data_direction dir,
/* Toggle wake to exit out of M2 */
mhi_cntrl->wake_toggle(mhi_cntrl);
- /* Generate the TRE */
- buf_info = buf_ring->wp;
-
- buf_info->v_addr = skb->data;
- buf_info->cb_buf = skb;
- buf_info->wp = tre_ring->wp;
- buf_info->dir = mhi_chan->dir;
- buf_info->len = len;
- ret = mhi_cntrl->map_single(mhi_cntrl, buf_info);
- if (ret)
- goto map_error;
-
- mhi_tre = tre_ring->wp;
-
- mhi_tre->ptr = MHI_TRE_DATA_PTR(buf_info->p_addr);
- mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(buf_info->len);
- mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(1, 1, 0, 0);
+ buf_info.v_addr = skb->data;
+ buf_info.cb_buf = skb;
+ buf_info.len = len;
- /* increment WP */
- mhi_add_ring_element(mhi_cntrl, tre_ring);
- mhi_add_ring_element(mhi_cntrl, buf_ring);
+ ret = mhi_gen_tre(mhi_cntrl, mhi_chan, _info, mflags);
+ if (unlikely(ret)) {
+ read_unlock_bh(_cntrl->pm_lock);
+ return ret;
+ }
if (mhi_chan->dir == DMA_TO_DEVICE)
atomic_inc(_cntrl->pending_pkts);
@@ -980,11 +966,6 @@ int mhi_queue_skb(struct mhi_device *mhi_dev, enum
dma_data_direction dir,
read_unlock_bh(_cntrl->pm_lock);
return 0;
-
-map_error:
- read_unlock_bh(_cntrl->pm_lock);
-
- return ret;
}
EXPORT_SYMBOL_GPL(mhi_queue_skb);
@@ -996,9 +977,8 @@ int mhi_queue_dma(struct mhi_device *mhi_dev, enum
dma_data_direction dir,
mhi_dev->dl_chan;
struct device *dev = _cntrl->mhi_dev->dev;
struct mhi_ring *tre_ring = _chan->tre_ring;
- struct mhi_ring *buf_ring = _chan->buf_ring;
- struct mhi_buf_info *buf_info;
- struct mhi_tre *mhi_tre;
+ struct mhi_buf_info buf_info = { };
+ int ret;
/* If MHI host pre-allocates buffers then client drivers cannot queue */
if (mhi_chan->pre_alloc)
@@ -1025,25 +1005,16 @@ int mhi_queue_dma(struct mhi_device *mhi_dev, enum
dma_data_direction dir,
/* Toggle wake to exit out of M2 */
mhi_cntrl->wake_toggle(mhi_cntrl);
- /* Generate the TRE */
- buf_info = buf_ring->wp;
- WARN_ON(buf_info->used);
- buf_info->p_addr = mhi_buf->dma_addr;
- buf_info->pre_mapped = true;
- buf_info->cb_buf = mhi_buf;
- buf_info->wp = tre_ring->wp;
- buf_info->dir = mhi_chan->dir;
- buf_info->len = len;
-
- mhi_tre = tre_ring->wp;
-
- mhi_tre->ptr = MHI_TRE_DATA_PTR(buf_info->p_addr);
- mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(buf_info->len);
- mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(1, 1, 0, 0);
+ buf_info.p_addr = mhi_buf->dma_addr;
+ buf_info.cb_buf = mhi_buf;
+ buf_info.pre_mapped = true;
+ buf_info.len =
[PATCH v5 7/8] bus: mhi: core: Improve debug logs for loading firmware
Add log messages to track boot flow errors and timeouts in SBL or AMSS
firmware loading to aid in debug.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
---
drivers/bus/mhi/core/boot.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index 05627fe..e5fcde1 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -121,7 +121,8 @@ static int __mhi_download_rddm_in_panic(struct
mhi_controller *mhi_cntrl)
ee = mhi_get_exec_env(mhi_cntrl);
}
- dev_dbg(dev, "Waiting for image download completion, current EE: %s\n",
+ dev_dbg(dev,
+ "Waiting for RDDM image download via BHIe, current EE:%s\n",
TO_MHI_EXEC_STR(ee));
while (retry--) {
@@ -152,11 +153,14 @@ static int __mhi_download_rddm_in_panic(struct
mhi_controller *mhi_cntrl)
int mhi_download_rddm_img(struct mhi_controller *mhi_cntrl, bool in_panic)
{
void __iomem *base = mhi_cntrl->bhie;
+ struct device *dev = _cntrl->mhi_dev->dev;
u32 rx_status;
if (in_panic)
return __mhi_download_rddm_in_panic(mhi_cntrl);
+ dev_dbg(dev, "Waiting for RDDM image download via BHIe\n");
+
/* Wait for the image download to complete */
wait_event_timeout(mhi_cntrl->state_event,
mhi_read_reg_field(mhi_cntrl, base,
@@ -174,6 +178,7 @@ static int mhi_fw_load_amss(struct mhi_controller
*mhi_cntrl,
const struct mhi_buf *mhi_buf)
{
void __iomem *base = mhi_cntrl->bhie;
+ struct device *dev = _cntrl->mhi_dev->dev;
rwlock_t *pm_lock = _cntrl->pm_lock;
u32 tx_status, sequence_id;
int ret;
@@ -184,6 +189,7 @@ static int mhi_fw_load_amss(struct mhi_controller
*mhi_cntrl,
return -EIO;
}
+ dev_dbg(dev, "Starting AMSS download via BHIe\n");
mhi_write_reg(mhi_cntrl, base, BHIE_TXVECADDR_HIGH_OFFS,
upper_32_bits(mhi_buf->dma_addr));
@@ -435,7 +441,12 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
release_firmware(firmware);
/* Error or in EDL mode, we're done */
- if (ret || mhi_cntrl->ee == MHI_EE_EDL)
+ if (ret) {
+ dev_err(dev, "MHI did not load SBL, ret:%d\n", ret);
+ return;
+ }
+
+ if (mhi_cntrl->ee == MHI_EE_EDL)
return;
write_lock_irq(_cntrl->pm_lock);
@@ -463,8 +474,10 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
if (!mhi_cntrl->fbc_download)
return;
- if (ret)
+ if (ret) {
+ dev_err(dev, "MHI did not enter READY state\n");
goto error_read;
+ }
/* Wait for the SBL event */
ret = wait_event_timeout(mhi_cntrl->state_event,
@@ -482,6 +495,8 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
ret = mhi_fw_load_amss(mhi_cntrl,
/* Vector table is the last entry */
_info->mhi_buf[image_info->entries - 1]);
+ if (ret)
+ dev_err(dev, "MHI did not load AMSS, ret:%d\n", ret);
release_firmware(firmware);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v5 6/8] bus: mhi: core: Return appropriate error codes for AMSS load failure
When loading AMSS firmware using BHIe protocol, return -ETIMEDOUT if no
response is received within the timeout or return -EIO in case of a
protocol returned failure or an MHI error state.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
---
drivers/bus/mhi/core/boot.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index 17c636b..05627fe 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -176,6 +176,7 @@ static int mhi_fw_load_amss(struct mhi_controller
*mhi_cntrl,
void __iomem *base = mhi_cntrl->bhie;
rwlock_t *pm_lock = _cntrl->pm_lock;
u32 tx_status, sequence_id;
+ int ret;
read_lock_bh(pm_lock);
if (!MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
@@ -198,19 +199,19 @@ static int mhi_fw_load_amss(struct mhi_controller
*mhi_cntrl,
read_unlock_bh(pm_lock);
/* Wait for the image download to complete */
- wait_event_timeout(mhi_cntrl->state_event,
- MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state) ||
- mhi_read_reg_field(mhi_cntrl, base,
- BHIE_TXVECSTATUS_OFFS,
- BHIE_TXVECSTATUS_STATUS_BMSK,
- BHIE_TXVECSTATUS_STATUS_SHFT,
- _status) || tx_status,
- msecs_to_jiffies(mhi_cntrl->timeout_ms));
-
- if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state))
+ ret = wait_event_timeout(mhi_cntrl->state_event,
+MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state) ||
+mhi_read_reg_field(mhi_cntrl, base,
+ BHIE_TXVECSTATUS_OFFS,
+ BHIE_TXVECSTATUS_STATUS_BMSK,
+ BHIE_TXVECSTATUS_STATUS_SHFT,
+ _status) || tx_status,
+msecs_to_jiffies(mhi_cntrl->timeout_ms));
+ if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state) ||
+ tx_status != BHIE_TXVECSTATUS_STATUS_XFER_COMPL)
return -EIO;
- return (tx_status == BHIE_TXVECSTATUS_STATUS_XFER_COMPL) ? 0 : -EIO;
+ return (!ret) ? -ETIMEDOUT : 0;
}
static int mhi_fw_load_sbl(struct mhi_controller *mhi_cntrl,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v5 4/8] bus: mhi: core: Read transfer length from an event properly
From: Hemant Kumar When MHI Driver receives an EOT event, it reads xfer_len from the event in the last TRE. The value is under control of the MHI device and never validated by Host MHI driver. The value should never be larger than the real size of the buffer but a malicious device can set the value 0x as maximum. This causes driver to memory overflow (both read or write). Fix this issue by reading minimum of transfer length from event and the buffer length provided. Signed-off-by: Hemant Kumar Signed-off-by: Bhaumik Bhatt Reviewed-by: Jeffrey Hugo --- drivers/bus/mhi/core/main.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c index e60ab21..159732e 100644 --- a/drivers/bus/mhi/core/main.c +++ b/drivers/bus/mhi/core/main.c @@ -514,7 +514,10 @@ static int parse_xfer_event(struct mhi_controller *mhi_cntrl, mhi_cntrl->unmap_single(mhi_cntrl, buf_info); result.buf_addr = buf_info->cb_buf; - result.bytes_xferd = xfer_len; + + /* truncate to buf len if xfer_len is larger */ + result.bytes_xferd = + min_t(u16, xfer_len, buf_info->len); mhi_del_ring_element(mhi_cntrl, buf_ring); mhi_del_ring_element(mhi_cntrl, tre_ring); local_rp = tre_ring->rp; @@ -598,7 +601,9 @@ static int parse_rsc_event(struct mhi_controller *mhi_cntrl, result.transaction_status = (ev_code == MHI_EV_CC_OVERFLOW) ? -EOVERFLOW : 0; - result.bytes_xferd = xfer_len; + + /* truncate to buf len if xfer_len is larger */ + result.bytes_xferd = min_t(u16, xfer_len, buf_info->len); result.buf_addr = buf_info->cb_buf; result.dir = mhi_chan->dir; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v5 5/8] bus: mhi: core: Handle firmware load using state worker
Upon power up, driver queues firmware worker thread if the execution
environment is PBL. Firmware worker is blocked with a timeout until
state worker gets a chance to run and unblock firmware worker. An
endpoint power up failure can be seen if state worker gets a chance to
run after firmware worker has timed out. Remove this dependency and
handle firmware load directly using state worker thread.
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
---
drivers/bus/mhi/core/boot.c | 18 +++---
drivers/bus/mhi/core/init.c | 1 -
drivers/bus/mhi/core/internal.h | 1 +
drivers/bus/mhi/core/pm.c | 6 +-
include/linux/mhi.h | 2 --
5 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
index ebad5eb..17c636b 100644
--- a/drivers/bus/mhi/core/boot.c
+++ b/drivers/bus/mhi/core/boot.c
@@ -377,30 +377,18 @@ static void mhi_firmware_copy(struct mhi_controller
*mhi_cntrl,
}
}
-void mhi_fw_load_worker(struct work_struct *work)
+void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
{
- struct mhi_controller *mhi_cntrl;
const struct firmware *firmware = NULL;
struct image_info *image_info;
- struct device *dev;
+ struct device *dev = _cntrl->mhi_dev->dev;
const char *fw_name;
void *buf;
dma_addr_t dma_addr;
size_t size;
int ret;
- mhi_cntrl = container_of(work, struct mhi_controller, fw_worker);
- dev = _cntrl->mhi_dev->dev;
-
- dev_dbg(dev, "Waiting for device to enter PBL from: %s\n",
- TO_MHI_EXEC_STR(mhi_cntrl->ee));
-
- ret = wait_event_timeout(mhi_cntrl->state_event,
-MHI_IN_PBL(mhi_cntrl->ee) ||
-MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state),
-msecs_to_jiffies(mhi_cntrl->timeout_ms));
-
- if (!ret || MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
+ if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
dev_err(dev, "Device MHI is not in valid state\n");
return;
}
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 1a93d24..6882206 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -835,7 +835,6 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
spin_lock_init(_cntrl->wlock);
INIT_WORK(_cntrl->st_worker, mhi_pm_st_worker);
INIT_WORK(_cntrl->syserr_worker, mhi_pm_sys_err_worker);
- INIT_WORK(_cntrl->fw_worker, mhi_fw_load_worker);
init_waitqueue_head(_cntrl->state_event);
mhi_cmd = mhi_cntrl->mhi_cmd;
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 40c47f9..0965ca3 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -627,6 +627,7 @@ void mhi_ring_chan_db(struct mhi_controller *mhi_cntrl,
void mhi_deinit_free_irq(struct mhi_controller *mhi_cntrl);
void mhi_rddm_prepare(struct mhi_controller *mhi_cntrl,
struct image_info *img_info);
+void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl);
int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
struct mhi_chan *mhi_chan);
int mhi_init_chan_ctxt(struct mhi_controller *mhi_cntrl,
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index e7c8318..3cc238a 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -528,7 +528,6 @@ static void mhi_pm_disable_transition(struct mhi_controller
*mhi_cntrl,
dev_dbg(dev, "Waiting for all pending threads to complete\n");
wake_up_all(_cntrl->state_event);
flush_work(_cntrl->st_worker);
- flush_work(_cntrl->fw_worker);
dev_dbg(dev, "Reset all active channels and remove MHI devices\n");
device_for_each_child(mhi_cntrl->cntrl_dev, NULL, mhi_destroy_device);
@@ -643,7 +642,7 @@ void mhi_pm_st_worker(struct work_struct *work)
mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
write_unlock_irq(_cntrl->pm_lock);
if (MHI_IN_PBL(mhi_cntrl->ee))
- wake_up_all(_cntrl->state_event);
+ mhi_fw_load_handler(mhi_cntrl);
break;
case DEV_ST_TRANSITION_SBL:
write_lock_irq(_cntrl->pm_lock);
@@ -976,9 +975,6 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
next_state = MHI_IN_PBL(current_ee) ?
DEV_ST_TRANSITION_PBL : DEV_ST_TRANSITION_READY;
- if (next_state == DEV_ST_TRANSITION_PBL)
- schedule_work(_cntrl->fw_worker);
-
mhi_queue_state_transition(mhi_cntrl, next_state);
mutex_unlock(_cntrl->pm_mutex);
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index e909b8f..2b20b9c 100644
[PATCH v5 2/8] bus: mhi: core: Cache intmod from mhi event to mhi channel
From: Hemant Kumar
Driver is using zero initialized intmod value from mhi channel when
configuring TRE for bei field. This prevents interrupt moderation to
take effect in case it is supported by an event ring. Fix this by
copying intmod value from associated event ring to mhi channel upon
registering mhi controller.
Signed-off-by: Hemant Kumar
Signed-off-by: Bhaumik Bhatt
Reviewed-by: Jeffrey Hugo
---
drivers/bus/mhi/core/init.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index eb2ab05..1a93d24 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -863,6 +863,10 @@ int mhi_register_controller(struct mhi_controller
*mhi_cntrl,
mutex_init(_chan->mutex);
init_completion(_chan->completion);
rwlock_init(_chan->lock);
+
+ /* used in setting bei field of TRE */
+ mhi_event = _cntrl->mhi_event[mhi_chan->er_index];
+ mhi_chan->intmod = mhi_event->intmod;
}
if (mhi_cntrl->bounce_buf) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [RFC PATCH v12 6/9] media: tegra: Add Tegra210 Video input driver
05.05.2020 05:31, Sowjanya Komatineni пишет: > Tegra210 contains a powerful Video Input (VI) hardware controller > which can support up to 6 MIPI CSI camera sensors. > > Each Tegra CSI port can be one-to-one mapped to VI channel and can > capture from an external camera sensor connected to CSI or from > built-in test pattern generator. > > Tegra210 supports built-in test pattern generator from CSI to VI. > > This patch adds a v4l2 capture driver with media interface for > Tegra210 built-in CSI to VI test pattern generator. > > This patch includes TPG support only and all the video pipeline > configuration happens through the video device node. > > Acked-by: Thierry Reding > Signed-off-by: Sowjanya Komatineni > --- Reviewed-by: Dmitry Osipenko
[PATCH net-next] ixgbe: fix signed-integer-overflow warning
ubsan report this warning, fix it by adding a unsigned suffix. UBSAN: signed-integer-overflow in drivers/net/ethernet/intel/ixgbe/ixgbe_common.c:2246:26 65535 * 65537 cannot be represented in type 'int' CPU: 21 PID: 7 Comm: kworker/u256:0 Not tainted 5.7.0-rc3-debug+ #39 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 03/27/2020 Workqueue: ixgbe ixgbe_service_task [ixgbe] Call trace: dump_backtrace+0x0/0x3f0 show_stack+0x28/0x38 dump_stack+0x154/0x1e4 ubsan_epilogue+0x18/0x60 handle_overflow+0xf8/0x148 __ubsan_handle_mul_overflow+0x34/0x48 ixgbe_fc_enable_generic+0x4d0/0x590 [ixgbe] ixgbe_service_task+0xc20/0x1f78 [ixgbe] process_one_work+0x8f0/0xf18 worker_thread+0x430/0x6d0 kthread+0x218/0x238 ret_from_fork+0x10/0x18 Reported-by: Hulk Robot Signed-off-by: Xie XiuQi --- drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c index 0bd1294ba517..39c5e6fdb72c 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c @@ -2243,7 +2243,7 @@ s32 ixgbe_fc_enable_generic(struct ixgbe_hw *hw) } /* Configure pause time (2 TCs per register) */ - reg = hw->fc.pause_time * 0x00010001; + reg = hw->fc.pause_time * 0x00010001U; for (i = 0; i < (MAX_TRAFFIC_CLASS / 2); i++) IXGBE_WRITE_REG(hw, IXGBE_FCTTV(i), reg); -- 2.20.1
[PATCH 3/3] platform/x86: Intel PMT Telemetry capability driver
PMT Telemetry is a capability of the Intel Platform Monitoring Technology. The Telemetry capability provides access to device telemetry metrics that provide hardware performance data to users from continuous, memory mapped, read-only register spaces. Register mappings are not provided by the driver. Instead, a GUID is read from a header for each endpoint. The GUID identifies the device and is to be used with an XML, provided by the vendor, to discover the available set of metrics and their register mapping. This allows firmware updates to modify the register space without needing to update the driver every time with new mappings. Firmware writes a new GUID in this case to specify the new mapping. Software tools with access to the associated XML file can then interpret the changes. This module manages access to all PMT Telemetry endpoints on a system, regardless of the device exporting them. It creates an intel_pmt_telem class to manage the list. For each endpoint, sysfs files provide GUID and size information as well as a pointer to the parent device the telemetry comes from. Software may discover the association between endpoints and devices by iterating through the list in sysfs, or by looking for the existence of the class folder under the device of interest. A device node of the same name allows software to then map the telemetry space for direct access. Signed-off-by: David E. Box Signed-off-by: Alexander Duyck --- .../ABI/testing/sysfs-class-intel_pmt_telem | 46 +++ MAINTAINERS | 1 + drivers/platform/x86/Kconfig | 10 + drivers/platform/x86/Makefile | 1 + drivers/platform/x86/intel_pmt_telem.c| 356 ++ drivers/platform/x86/intel_pmt_telem.h| 20 + 6 files changed, 434 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-intel_pmt_telem create mode 100644 drivers/platform/x86/intel_pmt_telem.c create mode 100644 drivers/platform/x86/intel_pmt_telem.h diff --git a/Documentation/ABI/testing/sysfs-class-intel_pmt_telem b/Documentation/ABI/testing/sysfs-class-intel_pmt_telem new file mode 100644 index ..cdd9a16b31f3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-intel_pmt_telem @@ -0,0 +1,46 @@ +What: /sys/class/intel_pmt_telem/ +Date: April 2020 +KernelVersion: 5.8 +Contact: David Box +Description: + The intel_pmt_telem/ class directory contains information for + devices that expose hardware telemetry using Intel Platform + Monitoring Technology (PMT) + +What: /sys/class/intel_pmt_telem/telemX +Date: April 2020 +KernelVersion: 5.8 +Contact: David Box +Description: + The telemX directory contains files describing an instance of a + PMT telemetry device that exposes hardware telemetry. Each + telemX device has an associated /dev/telemX node. This node can + be opened and mapped to access the telemetry space of the + device. The register layout of the telemetry space is + determined from an XML file of specific guid for the corresponding + parent device. + +What: /sys/class/intel_pmt_telem/telemX/guid +Date: April 2020 +KernelVersion: 5.8 +Contact: David Box +Description: + (RO) The guid for this telemetry device. The guid identifies + the version of the XML file for the parent device that should + be used to determine the register layout. + +What: /sys/class/intel_pmt_telem/telemX/size +Date: April 2020 +KernelVersion: 5.8 +Contact: David Box +Description: + (RO) The size of telemetry region in bytes that corresponds to + the mapping size for the /dev/telemX device node. + +What: /sys/class/intel_pmt_telem/telemX/offset +Date: April 2020 +KernelVersion: 5.8 +Contact: David Box +Description: + (RO) The offset of telemetry region in bytes that corresponds to + the mapping for the /dev/telemX device node. diff --git a/MAINTAINERS b/MAINTAINERS index bacf7ecd4d21..c49a9d3a28d2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8787,6 +8787,7 @@ INTEL PMT DRIVER M: "David E. Box" S: Maintained F: drivers/mfd/intel_pmt.c +F: drivers/platform/x86/intel_pmt_* INTEL UNCORE FREQUENCY CONTROL M: Srinivas Pandruvada diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 0ad7ad8cf8e1..dd734eb66e74 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -1368,6 +1368,16 @@ config INTEL_TELEMETRY directly via debugfs files. Various tools may use this interface for SoC state monitoring. +config INTEL_PMT_TELEM + tristate "Intel PMT telemetry driver" + help +The Intel Platform Monitory
Re: [PATCH v4 8/8] bus: mhi: core: Ensure non-zero session or sequence ID values are used
On 2020-05-04 07:33, Jeffrey Hugo wrote: On 5/1/2020 8:32 PM, Bhaumik Bhatt wrote: While writing any sequence or session identifiers, it is possible that the host could write a zero value, whereas only non-zero values should be supported writes to those registers. Ensure that the host does not write a non-zero value for them and also log them in debug messages. Suggested-by: Jeffrey Hugo Signed-off-by: Bhaumik Bhatt --- drivers/bus/mhi/core/boot.c | 15 +++ drivers/bus/mhi/core/internal.h | 1 + 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c index e5fcde1..9fe9c59 100644 --- a/drivers/bus/mhi/core/boot.c +++ b/drivers/bus/mhi/core/boot.c @@ -43,10 +43,7 @@ void mhi_rddm_prepare(struct mhi_controller *mhi_cntrl, lower_32_bits(mhi_buf->dma_addr)); mhi_write_reg(mhi_cntrl, base, BHIE_RXVECSIZE_OFFS, mhi_buf->len); - sequence_id = prandom_u32() & BHIE_RXVECSTATUS_SEQNUM_BMSK; - - if (unlikely(!sequence_id)) - sequence_id = 1; + sequence_id = (MHI_RANDOM_U32_NONZERO & BHIE_RXVECSTATUS_SEQNUM_BMSK); I don't think this math works. For example, if MHI_RANDOM_U32_NONZERO is 0x0FF0, and BHIE_RXVECSTATUS_SEQNUM_BMSK is 0xF, then sequence_id will end up being 0. In this case, SEQNUM BMSK is set to 0x3FFF so this change will still work as we only supplied a non-zero number macro to AND with the mask. However, I agree that may not be the case always that we would know the bitmask in advance so it is better to fix it for good. Thanks for the catch! I have updated the change to have the macro take the bitmask as a parameter and output a non-zero value.
[PATCH 2/3] mfd: Intel Platform Monitoring Technology support
Intel Platform Monitoring Technology (PMT) is an architecture for
enumerating and accessing hardware monitoring facilities. PMT supports
multiple types of monitoring capabilities. Capabilities are discovered
using PCIe DVSEC with the Intel VID. Each capability is discovered as a
separate DVSEC instance in a device's config space. This driver uses MFD to
manage the creation of platform devices for each type so that they may be
controlled by their own drivers (to be introduced). Support is included
for the 3 current capability types, Telemetry, Watcher, and Crashlog. The
features are available on new Intel platforms starting from Tiger Lake for
which support is added. Tiger Lake however will not support Watcher and
Crashlog even though the capabilities appear on the device. So add a quirk
facility and use it to disable them.
Signed-off-by: David E. Box
Signed-off-by: Alexander Duyck
---
MAINTAINERS | 5 ++
drivers/mfd/Kconfig | 10 +++
drivers/mfd/Makefile| 1 +
drivers/mfd/intel_pmt.c | 174
include/linux/intel-dvsec.h | 44 +
5 files changed, 234 insertions(+)
create mode 100644 drivers/mfd/intel_pmt.c
create mode 100644 include/linux/intel-dvsec.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db31497..bacf7ecd4d21 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8783,6 +8783,11 @@ S: Maintained
F: arch/x86/include/asm/intel_telemetry.h
F: drivers/platform/x86/intel_telemetry*
+INTEL PMT DRIVER
+M: "David E. Box"
+S: Maintained
+F: drivers/mfd/intel_pmt.c
+
INTEL UNCORE FREQUENCY CONTROL
M: Srinivas Pandruvada
L: platform-driver-...@vger.kernel.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0a59249198d3..c673031acdf1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -632,6 +632,16 @@ config MFD_INTEL_MSIC
Passage) chip. This chip embeds audio, battery, GPIO, etc.
devices used in Intel Medfield platforms.
+config MFD_INTEL_PMT
+ tristate "Intel Platform Monitoring Technology support"
+ depends on PCI
+ select MFD_CORE
+ help
+ The Intel Platform Monitoring Technology (PMT) is an interface that
+ provides access to hardware monitor registers. This driver supports
+ Telemetry, Watcher, and Crashlog PTM capabilities/devices for
+ platforms starting from Tiger Lake.
+
config MFD_IPAQ_MICRO
bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
depends on SA1100_H3100 || SA1100_H3600
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f935d10cbf0f..0041f673faa1 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -212,6 +212,7 @@ obj-$(CONFIG_MFD_INTEL_LPSS)+= intel-lpss.o
obj-$(CONFIG_MFD_INTEL_LPSS_PCI) += intel-lpss-pci.o
obj-$(CONFIG_MFD_INTEL_LPSS_ACPI) += intel-lpss-acpi.o
obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
+obj-$(CONFIG_MFD_INTEL_PMT)+= intel_pmt.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
diff --git a/drivers/mfd/intel_pmt.c b/drivers/mfd/intel_pmt.c
new file mode 100644
index ..c48a2b82ca99
--- /dev/null
+++ b/drivers/mfd/intel_pmt.c
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Platform Monitoring Technology MFD driver
+ *
+ * Copyright (c) 2020, Intel Corporation.
+ * All Rights Reserved.
+ *
+ * Authors: David E. Box
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TELEM_DEV_NAME "pmt_telemetry"
+#define WATCHER_DEV_NAME "pmt_watcher"
+#define CRASHLOG_DEV_NAME "pmt_crashlog"
+
+static const struct pmt_platform_info tgl_info = {
+ .quirks = PMT_QUIRK_NO_WATCHER | PMT_QUIRK_NO_CRASHLOG,
+};
+
+static int
+pmt_add_dev(struct pci_dev *pdev, struct intel_dvsec_header *header,
+ struct pmt_platform_info *info)
+{
+ struct mfd_cell *cell, *tmp;
+ const char *name;
+ int i;
+
+ switch (header->id) {
+ case DVSEC_INTEL_ID_TELEM:
+ name = TELEM_DEV_NAME;
+ break;
+ case DVSEC_INTEL_ID_WATCHER:
+ if (info->quirks && PMT_QUIRK_NO_WATCHER) {
+ dev_info(>dev, "Watcher not supported\n");
+ return 0;
+ }
+ name = WATCHER_DEV_NAME;
+ break;
+ case DVSEC_INTEL_ID_CRASHLOG:
+ if (info->quirks && PMT_QUIRK_NO_WATCHER) {
+ dev_info(>dev, "Crashlog not supported\n");
+ return 0;
+ }
+ name = CRASHLOG_DEV_NAME;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ cell = devm_kcalloc(>dev, header->num_entries,
+ sizeof(*cell), GFP_KERNEL);
+ if
[RFC PATCH v12 8/9] dt-bindings: reset: Add ID for Tegra210 VI reset
This patch adds ID for Tegra210 VI controller reset to use with device tree. Acked-by: Rob Herring Signed-off-by: Sowjanya Komatineni --- include/dt-bindings/reset/tegra210-car.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/reset/tegra210-car.h b/include/dt-bindings/reset/tegra210-car.h index 9dc84ec..8755946 100644 --- a/include/dt-bindings/reset/tegra210-car.h +++ b/include/dt-bindings/reset/tegra210-car.h @@ -10,5 +10,6 @@ #define TEGRA210_RESET(x) (7 * 32 + (x)) #define TEGRA210_RST_DFLL_DVCO TEGRA210_RESET(0) #define TEGRA210_RST_ADSP TEGRA210_RESET(1) +#define TEGRA210_RST_VI20 #endif /* _DT_BINDINGS_RESET_TEGRA210_CAR_H */ -- 2.7.4
[RFC PATCH v12 6/9] media: tegra: Add Tegra210 Video input driver
Tegra210 contains a powerful Video Input (VI) hardware controller which can support up to 6 MIPI CSI camera sensors. Each Tegra CSI port can be one-to-one mapped to VI channel and can capture from an external camera sensor connected to CSI or from built-in test pattern generator. Tegra210 supports built-in test pattern generator from CSI to VI. This patch adds a v4l2 capture driver with media interface for Tegra210 built-in CSI to VI test pattern generator. This patch includes TPG support only and all the video pipeline configuration happens through the video device node. Acked-by: Thierry Reding Signed-off-by: Sowjanya Komatineni --- drivers/staging/media/Kconfig|2 + drivers/staging/media/Makefile |1 + drivers/staging/media/tegra-video/Kconfig| 12 + drivers/staging/media/tegra-video/Makefile |8 + drivers/staging/media/tegra-video/TODO | 11 + drivers/staging/media/tegra-video/csi.c | 539 + drivers/staging/media/tegra-video/csi.h | 147 drivers/staging/media/tegra-video/tegra210.c | 978 +++ drivers/staging/media/tegra-video/vi.c | 1074 ++ drivers/staging/media/tegra-video/vi.h | 257 ++ drivers/staging/media/tegra-video/video.c| 155 drivers/staging/media/tegra-video/video.h| 29 + 12 files changed, 3213 insertions(+) create mode 100644 drivers/staging/media/tegra-video/Kconfig create mode 100644 drivers/staging/media/tegra-video/Makefile create mode 100644 drivers/staging/media/tegra-video/TODO create mode 100644 drivers/staging/media/tegra-video/csi.c create mode 100644 drivers/staging/media/tegra-video/csi.h create mode 100644 drivers/staging/media/tegra-video/tegra210.c create mode 100644 drivers/staging/media/tegra-video/vi.c create mode 100644 drivers/staging/media/tegra-video/vi.h create mode 100644 drivers/staging/media/tegra-video/video.c create mode 100644 drivers/staging/media/tegra-video/video.h diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index c6b4fb5..6e54ba1 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -36,6 +36,8 @@ source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" +source "drivers/staging/media/tegra-video/Kconfig" + source "drivers/staging/media/ipu3/Kconfig" source "drivers/staging/media/soc_camera/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 8b24be1..c38b83b 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_VIDEO_MESON_VDEC) += meson/vdec/ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_ROCKCHIP_VDEC) += rkvdec/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ +obj-$(CONFIG_VIDEO_TEGRA) += tegra-video/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_HANTRO) += hantro/ obj-$(CONFIG_VIDEO_IPU3_IMGU) += ipu3/ diff --git a/drivers/staging/media/tegra-video/Kconfig b/drivers/staging/media/tegra-video/Kconfig new file mode 100644 index 000..6cee329 --- /dev/null +++ b/drivers/staging/media/tegra-video/Kconfig @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0-only +config VIDEO_TEGRA + tristate "NVIDIA Tegra VI driver" + depends on TEGRA_HOST1X || COMPILE_TEST + select VIDEO_V4L2 + select MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + help + Choose this option if you have an NVIDIA Tegra SoC. + + To compile this driver as a module, choose M here: the module + will be called tegra-video. diff --git a/drivers/staging/media/tegra-video/Makefile b/drivers/staging/media/tegra-video/Makefile new file mode 100644 index 000..dfa2ef8 --- /dev/null +++ b/drivers/staging/media/tegra-video/Makefile @@ -0,0 +1,8 @@ +# SPDX-License-Identifier: GPL-2.0 +tegra-video-objs := \ + video.o \ + vi.o \ + csi.o + +tegra-video-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o +obj-$(CONFIG_VIDEO_TEGRA) += tegra-video.o diff --git a/drivers/staging/media/tegra-video/TODO b/drivers/staging/media/tegra-video/TODO new file mode 100644 index 000..6ceb7549 --- /dev/null +++ b/drivers/staging/media/tegra-video/TODO @@ -0,0 +1,11 @@ +TODO list +* Currently driver supports Tegra build-in TPG only with direct media links + from CSI to VI. Add kernel config CONFIG_VIDEO_TEGRA_TPG and update the + driver to do TPG Vs Sensor media links based on CONFIG_VIDEO_TEGRA_TPG. +* Add real camera sensor capture support. +* Add Tegra CSI MIPI pads calibration. +* Add MIPI clock Settle time computation based on the data rate. +* Add support for Ganged mode. +* Add RAW10 packed video format support to Tegra210 video formats. +* Add support for suspend and resume. +* Make sure v4l2-compliance tests pass with all of the above implementations. diff --git
[RFC PATCH v12 9/9] arm64: tegra: Add Tegra VI CSI support in device tree
Tegra210 contains VI controller for video input capture from MIPI
CSI camera sensors and also supports built-in test pattern generator.
CSI ports can be one-to-one mapped to VI channels for capturing from
an external sensor or from built-in test pattern generator.
This patch adds support for VI and CSI and enables them in Tegra210
device tree.
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 10 ++
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 46 +-
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
index 313a4c2..b57d837 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
@@ -14,6 +14,16 @@
status = "okay";
};
+ vi@5408 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <_dsi_csi>;
+
+ csi@838 {
+ status = "okay";
+ };
+ };
+
sor@5458 {
status = "okay";
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 29a43d7..2a02b76 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -137,9 +137,44 @@
vi@5408 {
compatible = "nvidia,tegra210-vi";
- reg = <0x0 0x5408 0x0 0x0004>;
+ reg = <0x0 0x5408 0x0 0x700>;
interrupts = ;
status = "disabled";
+ assigned-clocks = <_car TEGRA210_CLK_VI>;
+ assigned-clock-parents = <_car
TEGRA210_CLK_PLL_C4_OUT0>;
+
+ clocks = <_car TEGRA210_CLK_VI>;
+ power-domains = <_venc>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0x0 0x0 0x5408 0x2000>;
+
+ csi@838 {
+ compatible = "nvidia,tegra210-csi";
+ reg = <0x838 0x1300>;
+ status = "disabled";
+ assigned-clocks = <_car
TEGRA210_CLK_CILAB>,
+ <_car
TEGRA210_CLK_CILCD>,
+ <_car
TEGRA210_CLK_CILE>,
+ <_car
TEGRA210_CLK_CSI_TPG>;
+ assigned-clock-parents = <_car
TEGRA210_CLK_PLL_P>,
+<_car
TEGRA210_CLK_PLL_P>,
+<_car
TEGRA210_CLK_PLL_P>;
+ assigned-clock-rates = <10200>,
+ <10200>,
+ <10200>,
+ <97200>;
+
+ clocks = <_car TEGRA210_CLK_CSI>,
+<_car TEGRA210_CLK_CILAB>,
+<_car TEGRA210_CLK_CILCD>,
+<_car TEGRA210_CLK_CILE>,
+<_car TEGRA210_CLK_CSI_TPG>;
+ clock-names = "csi", "cilab", "cilcd", "cile",
"csi_tpg";
+ power-domains = <_sor>;
+ };
};
tsec@5410 {
@@ -839,6 +874,15 @@
reset-names = "vic";
#power-domain-cells = <0>;
};
+
+ pd_venc: venc {
+ clocks = <_car TEGRA210_CLK_VI>,
+<_car TEGRA210_CLK_CSI>;
+ resets = < TEGRA210_MC_RESET_VI>,
+<_car TEGRA210_RST_VI>,
+<_car TEGRA210_CLK_CSI>;
+ #power-domain-cells = <0>;
+ };
};
sdmmc1_3v3: sdmmc1-3v3 {
--
2.7.4
[RFC PATCH v12 4/9] clk: tegra: Add Tegra210 CSI TPG clock gate
Tegra210 CSI hardware internally uses PLLD for internal test pattern
generator logic.
PLLD_BASE register in CAR has a bit CSI_CLK_SOURCE to enable PLLD
out to CSI during TPG mode.
This patch adds this CSI TPG clock gate to Tegra210 clock driver
to allow Tegra video driver to ungate CSI TPG clock during TPG mode
and gate during non TPG mode.
Acked-by: Stephen Boyd
Signed-off-by: Sowjanya Komatineni
---
drivers/clk/tegra/clk-tegra210.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/tegra/clk-tegra210.c b/drivers/clk/tegra/clk-tegra210.c
index f2bb188..68cbb98 100644
--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -3076,6 +3076,13 @@ static __init void tegra210_periph_clk_init(struct
device_node *np,
periph_clk_enb_refcnt);
clks[TEGRA210_CLK_DSIB] = clk;
+ /* csi_tpg */
+ clk = clk_register_gate(NULL, "csi_tpg", "pll_d",
+ CLK_SET_RATE_PARENT, clk_base + PLLD_BASE,
+ 23, 0, _d_lock);
+ clk_register_clkdev(clk, "csi_tpg", NULL);
+ clks[TEGRA210_CLK_CSI_TPG] = clk;
+
/* la */
clk = tegra_clk_register_periph("la", la_parents,
ARRAY_SIZE(la_parents), _la, clk_base,
--
2.7.4
[RFC PATCH v12 2/9] arm64: tegra: Add reset-cells to mc
Tegra210 device tree is missing reset-cells property for mc node.
This patch fixes it.
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 909960a..29a43d7 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -894,6 +894,7 @@
interrupts = ;
#iommu-cells = <1>;
+ #reset-cells = <1>;
};
emc: external-memory-controller@7001b000 {
--
2.7.4
[RFC PATCH v12 3/9] dt-bindings: clock: tegra: Add clk id for CSI TPG clock
Tegra210 uses PLLD out internally for CSI TPG. This patch adds clk id for this CSI TPG clock from PLLD. Acked-by: Rob Herring Acked-by: Stephen Boyd Signed-off-by: Sowjanya Komatineni --- include/dt-bindings/clock/tegra210-car.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/dt-bindings/clock/tegra210-car.h b/include/dt-bindings/clock/tegra210-car.h index 7684a9f..ab8b8a7 100644 --- a/include/dt-bindings/clock/tegra210-car.h +++ b/include/dt-bindings/clock/tegra210-car.h @@ -358,7 +358,7 @@ #define TEGRA210_CLK_PLL_A_OUT0_OUT_ADSP 324 /* 325 */ #define TEGRA210_CLK_OSC 326 -/* 327 */ +#define TEGRA210_CLK_CSI_TPG 327 /* 328 */ /* 329 */ /* 330 */ -- 2.7.4
[RFC PATCH v12 7/9] MAINTAINERS: Add Tegra Video driver section
Add maintainers and mailing list entries to Tegra Video driver section. Acked-by: Thierry Reding Signed-off-by: Sowjanya Komatineni --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index fe55b3f..611d7bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16652,6 +16652,16 @@ M: Laxman Dewangan S: Supported F: drivers/spi/spi-tegra* +TEGRA VIDEO DRIVER +M: Thierry Reding +M: Jonathan Hunter +M: Sowjanya Komatineni +L: linux-me...@vger.kernel.org +L: linux-te...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +F: drivers/staging/media/tegra/ + TEGRA XUSB PADCTL DRIVER M: JC Kuo S: Supported -- 2.7.4
[RFC PATCH v12 5/9] dt-binding: tegra: Add VI and CSI bindings
Tegra contains VI controller which can support up to 6 MIPI CSI
camera sensors.
Each Tegra CSI port from CSI unit can be one-to-one mapper to
VI channel and can capture from an external camera sensor or
from built-in test pattern generator.
This patch adds dt-bindings for Tegra VI and CSI.
Acked-by: Thierry Reding
Reviewed-by: Rob Herring
Signed-off-by: Sowjanya Komatineni
---
.../display/tegra/nvidia,tegra20-host1x.txt| 73 ++
1 file changed, 60 insertions(+), 13 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index 255..4731921 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -40,14 +40,30 @@ of the following host1x client modules:
Required properties:
- compatible: "nvidia,tegra-vi"
- - reg: Physical base address and length of the controller's registers.
+ - reg: Physical base address and length of the controller registers.
- interrupts: The interrupt outputs from the controller.
- - clocks: Must contain one entry, for the module clock.
+ - clocks: clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- - resets: Must contain an entry for each entry in reset-names.
-See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
-- vi
+ - Tegra20/Tegra30/Tegra114/Tegra124:
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+ - vi
+ - Tegra210:
+- power-domains: Must include venc powergate node as vi is in VE partition.
+ - Tegra210 has CSI part of VI sharing same host interface and register space.
+So, VI device node should have CSI child node.
+
+- csi: mipi csi interface to vi
+
+ Required properties:
+ - compatible: "nvidia,tegra210-csi"
+ - reg: Physical base address offset to parent and length of the
controller
+registers.
+ - clocks: Must contain entries csi, cilab, cilcd, cile, csi_tpg clocks.
+See ../clocks/clock-bindings.txt for details.
+ - power-domains: Must include sor powergate node as csicil is in
+SOR partition.
- epp: encoder pre-processor
@@ -309,13 +325,44 @@ Example:
reset-names = "mpe";
};
- vi {
- compatible = "nvidia,tegra20-vi";
- reg = <0x5408 0x0004>;
- interrupts = <0 69 0x04>;
- clocks = <_car TEGRA20_CLK_VI>;
- resets = <_car 100>;
- reset-names = "vi";
+ vi@5408 {
+ compatible = "nvidia,tegra210-vi";
+ reg = <0x0 0x5408 0x0 0x700>;
+ interrupts = ;
+ assigned-clocks = <_car TEGRA210_CLK_VI>;
+ assigned-clock-parents = <_car
TEGRA210_CLK_PLL_C4_OUT0>;
+
+ clocks = <_car TEGRA210_CLK_VI>;
+ power-domains = <_venc>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0x0 0x0 0x5408 0x2000>;
+
+ csi@838 {
+ compatible = "nvidia,tegra210-csi";
+ reg = <0x838 0x1300>;
+ assigned-clocks = <_car
TEGRA210_CLK_CILAB>,
+ <_car
TEGRA210_CLK_CILCD>,
+ <_car
TEGRA210_CLK_CILE>,
+ <_car
TEGRA210_CLK_CSI_TPG>;
+ assigned-clock-parents = <_car
TEGRA210_CLK_PLL_P>,
+<_car
TEGRA210_CLK_PLL_P>,
+<_car
TEGRA210_CLK_PLL_P>;
+ assigned-clock-rates = <10200>,
+ <10200>,
+ <10200>,
+ <97200>;
+
+ clocks = <_car TEGRA210_CLK_CSI>,
+<_car TEGRA210_CLK_CILAB>,
+<_car TEGRA210_CLK_CILCD>,
+<_car TEGRA210_CLK_CILE>,
+<_car TEGRA210_CLK_CSI_TPG>;
+ clock-names = "csi", "cilab", "cilcd", "cile",
"csi_tpg";
+ power-domains = <_sor>;
+
[RFC PATCH v12 0/9] Add Tegra driver for video capture
This series adds Tegra210 VI and CSI driver for built-in test pattern generator (TPG) capture. Tegra210 supports max 6 channels on VI and 6 ports on CSI where each CSI port is one-to-one mapped to VI channel for video capture. This series has TPG support only where it creates hard media links between CSI subdevice and VI video device without device graphs. v4l2-compliance results are available below the patch diff. [v12]: Includes, - v12 feedback - module.h got removed in v11 accidentally. Fixed it. - Removed freezable kthreads as we don't need them. - Patches rebased on latest linux-next [v11]: Includes, - v10 feedback [v10]: Includes, - updated patches for latest linux-next base - Kconfig update - minor cleanup/improvements [v9]: Includes, - small fix to explicitly check for both vi and csi channels availability before TPG setup and cleanup so in the cases of later Tegras where CSI is not child to VI and if either of the platform drivers are not registered, TPG setup will be skipped. [v8]: Includes, - minor change to use device managed allocation fo vi and csi for now. May need to change back to non device managed allocation later when support for direct host1x client driver unbind and bind is added. [v7]: Includes, - v6 feedback - moved registering v4l2 nodes and creating tpg media links to happen after both host1x client inits so during direct host1x client driver unbind and bind order of client unregister/register will not impact. - All channels resources and freeing happens during v4l2 device release callback. - module unload/load works with below host1x bus driver fix. http://patchwork.ozlabs.org/patch/1268191/ [v6]: Includes, - v5 feedback - fix for csi_tpg clock parent - fix to free channel resources in video device release callback for registered video devices as resource might still be in use when application holds handle to it during driver unbind. - added blanking intervals based on resolution and bpp for csi internal tpg. - added implementation for subdev pad ops enum_frame_size and enum_frame_interval. [v5]: Includes, - v4 feedback - fix for venc powergate mc reset order. - fix to have unbind and bind work during v4l2-ctl sleep and streaming. [v4]: Includes, - v3 feedback changes and some improvements - Fixes tegra_channel_buffer struct to use v4l2 buffer as first member. This also fixes crash of unable to handle kernel write to read-only memory. - Uses separate host1x sync ids for frame start and memory write ack as single sync id for both can cause sync loss between exact frame start and memory write ack events. - Uses client managed host1x syncpoints. - Includes fix to increment syncpoint counter to match cached value to synchronize in case of timeouts or missed hardware triggers. - Frame start and memory write ack syncpoint FIFO's are of size 2. So, updated capture logic to avoid adding more than 2 sync point condition requests to FIFOs to avoid overflow. - Implemented PM ops for runtime suspend and resume along with generic power domains to allow proper power gate and ungate sequencing along with MC VI flush during power gate. - Fixed Tegra210 device tree sor power domain clocks. - Added missing reset-cells to mc node. [v3]: Includes, - video device node handling set/get formats of all devices in the pipeline. - Removed subdev nodes. - Fixed frame sync timeout issue due to CSI clocks not properly set for corresponding blocks. - uses minimum 3 buffers to be queued to fixed memory race between DMA writes and userspace reads causing kernel hang reporting kernel write to read-only memory. - Improved capture threads and done threads to avoid possible race conditions and added recovery in case of frame sync timeout. - Passes all the V4L compliance tests. [v2]: Includes, - v0 feedback - Merged files to have Tegra specific separately - Moved CSI device as child to VI as Tegra210 CSI is part of VI sharing same host interface and register space. - Added link_validate for format validation. - Fixes for passing v4l2-compliance for media, video, and subdevices. [v1]: Includes, - Adds CSI TPG clock to Tegra210 clock driver - Host1x video driver with VI and CSI clients. - Support for Tegra210 only. - VI CSI TPG support with hard media links in driver. - Video formats supported by Tegra210 VI
[RFC PATCH v12 1/9] arm64: tegra: Fix sor powergate clocks and reset
Tegra210 device tree lists csi clock and reset under SOR powergate
node.
But Tegra210 has csicil in SOR partition and csi in VENC partition.
So, this patch includes fix for sor powergate node.
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index a550e7b..909960a 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -796,7 +796,9 @@
pd_sor: sor {
clocks = <_car TEGRA210_CLK_SOR0>,
<_car TEGRA210_CLK_SOR1>,
-<_car TEGRA210_CLK_CSI>,
+<_car TEGRA210_CLK_CILAB>,
+<_car TEGRA210_CLK_CILCD>,
+<_car TEGRA210_CLK_CILE>,
<_car TEGRA210_CLK_DSIA>,
<_car TEGRA210_CLK_DSIB>,
<_car TEGRA210_CLK_DPAUX>,
@@ -804,7 +806,6 @@
<_car TEGRA210_CLK_MIPI_CAL>;
resets = <_car TEGRA210_CLK_SOR0>,
<_car TEGRA210_CLK_SOR1>,
-<_car TEGRA210_CLK_CSI>,
<_car TEGRA210_CLK_DSIA>,
<_car TEGRA210_CLK_DSIB>,
<_car TEGRA210_CLK_DPAUX>,
--
2.7.4
[PATCH v7 2/6] ARM: tegra: Add device-tree for ASUS Google Nexus 7
There are few hardware variants of NVIDIA Tegra30-based Nexus 7 device:
1. WiFi-only (named Grouper)
2. GSM (named Tilapia)
3. Using Maxim PMIC (E1565 board ID)
4. Using Ti PMIC (PM269 board ID)
This patch adds device-trees for known and tested variants.
Link: https://wiki.postmarketos.org/wiki/Google_Nexus_7_2012_(asus-grouper)
Tested-by: Pedro Ângelo
Tested-by: Matt Merhar
Tested-by: Zack Pearsall
Signed-off-by: David Heidelberg
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/Makefile|3 +
.../dts/tegra30-asus-nexus7-grouper-E1565.dts |9 +
.../dts/tegra30-asus-nexus7-grouper-PM269.dts |9 +
.../tegra30-asus-nexus7-grouper-common.dtsi | 2503 +
...egra30-asus-nexus7-grouper-maxim-pmic.dtsi | 187 ++
.../tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 150 +
.../boot/dts/tegra30-asus-nexus7-grouper.dtsi | 462 +++
.../dts/tegra30-asus-nexus7-tilapia-E1565.dts |9 +
.../boot/dts/tegra30-asus-nexus7-tilapia.dtsi | 548
9 files changed, 3880 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
create mode 100644
arch/arm/boot/dts/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper.dtsi
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-tilapia-E1565.dts
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-tilapia.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 79f5e04559e6..e9c4c903b309 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1203,6 +1203,9 @@ dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
dtb-$(CONFIG_ARCH_TEGRA_3x_SOC) += \
tegra30-apalis-eval.dtb \
tegra30-apalis-v1.1-eval.dtb \
+ tegra30-asus-nexus7-grouper-PM269.dtb \
+ tegra30-asus-nexus7-grouper-E1565.dtb \
+ tegra30-asus-nexus7-tilapia-E1565.dtb \
tegra30-beaver.dtb \
tegra30-cardhu-a02.dtb \
tegra30-cardhu-a04.dtb \
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
new file mode 100644
index ..a25b8560b0cd
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "tegra30-asus-nexus7-grouper-maxim-pmic.dtsi"
+#include "tegra30-asus-nexus7-grouper.dtsi"
+
+/ {
+ model = "ASUS Google Nexus 7 (Project Nakasi / ME370T) E1565";
+};
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
new file mode 100644
index ..06ef13ea5df8
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "tegra30-asus-nexus7-grouper-ti-pmic.dtsi"
+#include "tegra30-asus-nexus7-grouper.dtsi"
+
+/ {
+ model = "ASUS Google Nexus 7 (Project Nakasi / ME370T) PM269";
+};
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
new file mode 100644
index ..3c43bc5d8c74
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
@@ -0,0 +1,2503 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+
+#include "tegra30.dtsi"
+#include "tegra30-cpu-opp.dtsi"
+#include "tegra30-cpu-opp-microvolt.dtsi"
+
+/ {
+ aliases {
+ rtc0 =
+ rtc1 = "/rtc@7000e000";
+
+ serial1 = /* Bluetooth */
+ serial2 = /* GPS */
+ };
+
+ /*
+* The decompressor and also some bootloaders rely on a
+* pre-existing /chosen node to be available to insert the
+* command line and merge other ATAGS info.
+*/
+ chosen {};
+
+ memory@8000 {
+ reg = <0x8000 0x4000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,cma@8000 {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0x8000 0x3000>;
+ size = <0x1000>; /* 256MiB */
+ linux,cma-default;
+ reusable;
+ };
+
+ ramoops@bfdf {
+ compatible = "ramoops";
+ reg = <0xbfdf 0x1>; /* 64kB */
+ console-size = <0x8000>;/* 32kB */
+ record-size = <0x400>; /* 1kB */
+ ecc-size = <16>;
+ };
+
+
[PATCH v7 1/6] ARM: tegra: Add device-tree for Acer Iconia Tab A500
Add device-tree for Acer Iconia Tab A500, which is NVIDIA Tegra20-based
tablet device.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/Makefile|1 +
.../boot/dts/tegra20-acer-a500-picasso.dts| 1457 +
2 files changed, 1458 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9eff9be935e..79f5e04559e6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1189,6 +1189,7 @@ dtb-$(CONFIG_MACH_SUNIV) += \
dtb-$(CONFIG_ARCH_TANGO) += \
tango4-vantage-1172.dtb
dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
+ tegra20-acer-a500-picasso.dtb \
tegra20-harmony.dtb \
tegra20-colibri-eval-v3.dtb \
tegra20-colibri-iris.dtb \
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
new file mode 100644
index ..e64f00ce8028
--- /dev/null
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -0,0 +1,1457 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include
+#include
+#include
+
+#include "tegra20.dtsi"
+#include "tegra20-cpu-opp.dtsi"
+#include "tegra20-cpu-opp-microvolt.dtsi"
+
+/ {
+ model = "Acer Iconia Tab A500";
+ compatible = "acer,picasso", "nvidia,tegra20";
+
+ aliases {
+ rtc0 =
+ rtc1 = "/rtc@7000e000";
+
+ serial0 = /* Docking station */
+ serial1 = /* Bluetooth */
+ serial2 = /* GPS */
+ };
+
+ /*
+* The decompressor and also some bootloaders rely on a
+* pre-existing /chosen node to be available to insert the
+* command line and merge other ATAGS info.
+*/
+ chosen {};
+
+ memory@0 {
+ reg = <0x 0x4000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ ramoops@2ffe {
+ compatible = "ramoops";
+ reg = <0x2ffe 0x1>; /* 64kB */
+ console-size = <0x8000>;/* 32kB */
+ record-size = <0x400>; /* 1kB */
+ ecc-size = <16>;
+ };
+
+ linux,cma@3000 {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0x3000 0x1000>;
+ size = <0x1000>; /* 256MiB */
+ linux,cma-default;
+ reusable;
+ };
+ };
+
+ host1x@5000 {
+ dc@5420 {
+ rgb {
+ status = "okay";
+
+ port@0 {
+ lvds_output: endpoint {
+ remote-endpoint =
<_encoder_input>;
+ bus-width = <18>;
+ };
+ };
+ };
+ };
+
+ hdmi@5428 {
+ status = "okay";
+
+ vdd-supply = <_vdd_reg>;
+ pll-supply = <_pll_reg>;
+ hdmi-supply = <_5v0_sys>;
+
+ nvidia,ddc-i2c-bus = <_ddc>;
+ nvidia,hpd-gpio = < TEGRA_GPIO(N, 7)
+ GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ pinmux@7014 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+
+ state_default: pinmux {
+ ata {
+ nvidia,pins = "ata";
+ nvidia,function = "ide";
+ };
+ atb {
+ nvidia,pins = "atb", "gma", "gme";
+ nvidia,function = "sdio4";
+ };
+ atc {
+ nvidia,pins = "atc";
+ nvidia,function = "nand";
+ };
+ atd {
+ nvidia,pins = "atd", "ate", "gmb", "spia",
+ "spib", "spic";
+ nvidia,function = "gmi";
+ };
+ cdev1 {
+ nvidia,pins = "cdev1";
+ nvidia,function = "plla_out";
+ };
+ cdev2 {
+ nvidia,pins = "cdev2";
+ nvidia,function = "pllp_out4";
+ };
+ crtp {
+ nvidia,pins = "crtp", "lm1";
[PATCH v7 0/6] Support NVIDIA Tegra-based Acer A500 and Nexus 7 devices
Hello,
This series introduces upstream kernel support for Acer Iconia Tab A500
and ASUS Google Nexus 7 tablet devices. Please review and apply, thanks
in advance.
Changelog:
v7: - This version brings support for a Nexus 7 variant that uses Ti PMIC
instead of the Maxim PMIC. Previously we assumed that variant with
the Ti PMIC doesn't exist in a wild, but turned out that it was a
wrong assumption. In a result the device-trees are separated into
more DTSI pieces, which combined together form the final device-tree.
Thanks to Zack Pearsall for testing the Ti version!
- The camera voltage regulator is now preset to a correct 1.8v in the
Nexus 7 device-tree.
v6: - Corrected PMIC's RTC alias in the DTs. Sometime ago I renamed the
PMIC's node to match the modern upstream styling, but forgot to change
the RTC alias. Now PMIC RTC alias uses node's handle instead of string.
- Removed "panel: " handle from device trees, which became unused after
v5 and I just missed to remove it.
v5: - After spending some more time on adding LVDS encoder bridge support
to the Tegra DRM driver, I'm now having a second thought and agree
with Thierry Reding that in a longer run it should be better not to
mix old nvidia,panel with new output graph in device-tree. So the
nvidia,panel phandle is removed now in both A500 and Nexus 7 DTs.
v4: - Corrected CPU's thermal zone on both A500 and Nexus 7, which
should use the remote thermal sensor (Tegra chip) instead of the
local ("skin" temperature).
- Added default PMIC pinmux state on Nexus 7, for completeness.
- Added PMIC cpu_pwr_req GPIO hog on Nexus 7, for completeness.
- Renamed thermal sensor node label to NCT72 on Nexus 7 to match the
actual hardware (NCT72 is compatible with NCT1008). For completeness.
- Added always-on USB AVDD regulator on Nexus 7, which is controlled by
the PMIC GPIO. For completeness.
- Added PMIC GPIO enable-control to the 3v3_sys regulator on Nexus 7,
for completeness.
- Added CONFIG_NAMESPACES, CONFIG_USER_NS, CONFIG_SECCOMP and
CONFIG_PINCTRL_MAX77620 to the tegra_defconfig. The first three
options are must-have for the modern userspace, the last is somewhat
actual now since the default PMIC pinmux state is added to the N7 DT.
v3: - Improved device-tree node-names in accordance to review comments that
were made by Thierry Reding to v2.
- Corrected LVDS encoder powerdown-GPIO polarity on both A500 and Nexus 7
because I implemented the DRM bridges support in the Tegra DRM driver
and found that there was a mistake in the device-trees. The updated
polarity also matches the boards schematics. Now DRM bridges support
becomes mandatory since LVDS is getting disabled during of the encoder
driver probing. I'll send the DRM patch separately from this series.
- Replaced recently deprecated CONFIG_DRM_LVDS_ENCODER with the new
CONFIG_DRM_LVDS_CODEC in tegra_defconfig.
- Added more config options to tegra_defconfig, like pstore and thermal.
- Added atmel,cfg_name to the A500 DT, which is a new upcoming property
in 5.8+ that allows to specify the per-board hardware config file name.
v2: - Corrected "volume down" key-label in the grouper's device-tree and
improved some other names in device-trees.
- Added optional (upcoming in 5.8+) VDD/AVDD regulators to the touchscreen
node in A500 device-tree.
Dmitry Osipenko (6):
ARM: tegra: Add device-tree for Acer Iconia Tab A500
ARM: tegra: Add device-tree for ASUS Google Nexus 7
dt-bindings: Add vendor prefix for Acer Inc.
dt-bindings: ARM: tegra: Add Acer Iconia Tab A500
dt-bindings: ARM: tegra: Add ASUS Google Nexus 7
ARM: tegra_defconfig: Enable options useful for Nexus 7 and Acer A500
.../devicetree/bindings/arm/tegra.yaml| 10 +
.../devicetree/bindings/vendor-prefixes.yaml |2 +
arch/arm/boot/dts/Makefile|4 +
.../boot/dts/tegra20-acer-a500-picasso.dts| 1457 ++
.../dts/tegra30-asus-nexus7-grouper-E1565.dts |9 +
.../dts/tegra30-asus-nexus7-grouper-PM269.dts |9 +
.../tegra30-asus-nexus7-grouper-common.dtsi | 2503 +
...egra30-asus-nexus7-grouper-maxim-pmic.dtsi | 187 ++
.../tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 150 +
.../boot/dts/tegra30-asus-nexus7-grouper.dtsi | 462 +++
.../dts/tegra30-asus-nexus7-tilapia-E1565.dts |9 +
.../boot/dts/tegra30-asus-nexus7-tilapia.dtsi | 548
arch/arm/configs/tegra_defconfig | 42 +
13 files changed, 5392 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
[PATCH v7 6/6] ARM: tegra_defconfig: Enable options useful for Nexus 7 and Acer A500
Enable several very useful options and drivers for hardware that is found on Nexus 7 and Acer A500 tablet devices. Please note that some drivers may require firmware files extracted from original Android image. Link: https://github.com/digetx/linux-firmware Link: https://github.com/digetx/alsa-ucm-conf Signed-off-by: Dmitry Osipenko --- arch/arm/configs/tegra_defconfig | 42 1 file changed, 42 insertions(+) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index 0029259a6bf5..b382f06f835b 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -10,6 +10,8 @@ CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_DEBUG=y +CONFIG_NAMESPACES=y +CONFIG_USER_NS=y CONFIG_BLK_DEV_INITRD=y # CONFIG_ELF_CORE is not set CONFIG_EMBEDDED=y @@ -18,6 +20,7 @@ CONFIG_SLAB=y CONFIG_ARCH_TEGRA=y CONFIG_SMP=y CONFIG_HIGHMEM=y +CONFIG_SECCOMP=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_KEXEC=y @@ -63,11 +66,17 @@ CONFIG_BT_RFCOMM=y CONFIG_BT_BNEP=y CONFIG_BT_HIDP=y CONFIG_BT_HCIBTUSB=m +CONFIG_BT_HCIUART=y +CONFIG_BT_HCIUART_BCM=y CONFIG_CFG80211=y CONFIG_MAC80211=y CONFIG_RFKILL=y CONFIG_RFKILL_INPUT=y CONFIG_RFKILL_GPIO=y +CONFIG_NFC=y +CONFIG_NFC_HCI=y +CONFIG_NFC_SHDLC=y +CONFIG_NFC_PN544_I2C=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y CONFIG_PCI_MSI=y @@ -106,20 +115,24 @@ CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_TEGRA=y +CONFIG_KEYBOARD_CAP11XX=y CONFIG_KEYBOARD_CROS_EC=y CONFIG_MOUSE_PS2_ELANTECH=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ATMEL_MXT=y +CONFIG_TOUCHSCREEN_ELAN=y CONFIG_TOUCHSCREEN_WM97XX=y # CONFIG_TOUCHSCREEN_WM9705 is not set # CONFIG_TOUCHSCREEN_WM9713 is not set CONFIG_TOUCHSCREEN_STMPE=y CONFIG_INPUT_MISC=y +CONFIG_INPUT_GPIO_VIBRA=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_TEGRA=y +CONFIG_SERIAL_DEV_BUS=y # CONFIG_HW_RANDOM is not set # CONFIG_I2C_COMPAT is not set CONFIG_I2C_CHARDEV=y @@ -131,10 +144,12 @@ CONFIG_SPI_TEGRA114=y CONFIG_SPI_TEGRA20_SFLASH=y CONFIG_SPI_TEGRA20_SLINK=y CONFIG_PINCTRL_AS3722=y +CONFIG_PINCTRL_MAX77620=y CONFIG_PINCTRL_PALMAS=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_PCA953X=y CONFIG_GPIO_PCA953X_IRQ=y +CONFIG_GPIO_MAX77620=y CONFIG_GPIO_PALMAS=y CONFIG_GPIO_TPS6586X=y CONFIG_GPIO_TPS65910=y @@ -142,13 +157,21 @@ CONFIG_POWER_RESET=y CONFIG_POWER_RESET_AS3722=y CONFIG_POWER_RESET_GPIO=y CONFIG_BATTERY_SBS=y +CONFIG_BATTERY_BQ27XXX=y +CONFIG_CHARGER_GPIO=y +CONFIG_CHARGER_SMB347=y CONFIG_CHARGER_TPS65090=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y +CONFIG_THERMAL=y +CONFIG_THERMAL_STATISTICS=y +CONFIG_CPU_THERMAL=y CONFIG_WATCHDOG=y +CONFIG_MAX77620_WATCHDOG=y CONFIG_TEGRA_WATCHDOG=y CONFIG_MFD_AS3722=y CONFIG_MFD_CROS_EC=y +CONFIG_MFD_MAX77620=y CONFIG_MFD_MAX8907=y CONFIG_MFD_STMPE=y CONFIG_MFD_PALMAS=y @@ -159,6 +182,7 @@ CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_AS3722=y CONFIG_REGULATOR_GPIO=y +CONFIG_REGULATOR_MAX77620=y CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_PALMAS=y CONFIG_REGULATOR_TPS51632=y @@ -174,7 +198,10 @@ CONFIG_USB_GSPCA=y CONFIG_DRM=y CONFIG_DRM_NOUVEAU=m CONFIG_DRM_TEGRA=y +CONFIG_DRM_TEGRA_STAGING=y +CONFIG_DRM_PANEL_LVDS=y CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_LVDS_CODEC=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set @@ -238,6 +265,7 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_AS3722=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_MAX8907=y +CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_PALMAS=y CONFIG_RTC_DRV_TPS6586X=y CONFIG_RTC_DRV_TPS65910=y @@ -259,11 +287,18 @@ CONFIG_ARCH_TEGRA_2x_SOC=y CONFIG_ARCH_TEGRA_3x_SOC=y CONFIG_ARCH_TEGRA_114_SOC=y CONFIG_ARCH_TEGRA_124_SOC=y +CONFIG_PM_DEVFREQ=y +CONFIG_ARM_TEGRA_DEVFREQ=y +CONFIG_ARM_TEGRA20_DEVFREQ=y CONFIG_MEMORY=y CONFIG_IIO=y +CONFIG_KXCJK1013=y CONFIG_MPU3050_I2C=y +CONFIG_INV_MPU6050_I2C=y +CONFIG_AL3010=y CONFIG_SENSORS_ISL29018=y CONFIG_SENSORS_ISL29028=y +CONFIG_AK8974=y CONFIG_AK8975=y CONFIG_PWM=y CONFIG_PWM_TEGRA=y @@ -283,6 +318,13 @@ CONFIG_TMPFS_POSIX_ACL=y CONFIG_SQUASHFS=y CONFIG_SQUASHFS_LZO=y CONFIG_SQUASHFS_XZ=y +CONFIG_PSTORE=y +CONFIG_PSTORE_LZO_COMPRESS=y +CONFIG_PSTORE_LZ4_COMPRESS=y +CONFIG_PSTORE_LZ4HC_COMPRESS=y +CONFIG_PSTORE_842_COMPRESS=y +CONFIG_PSTORE_CONSOLE=y +CONFIG_PSTORE_RAM=y CONFIG_NFS_FS=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y -- 2.26.0
[PATCH v7 4/6] dt-bindings: ARM: tegra: Add Acer Iconia Tab A500
Add a binding for the Tegra20-based Acer Iconia Tab A500 tablet device. Signed-off-by: Dmitry Osipenko --- Documentation/devicetree/bindings/arm/tegra.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 60b38eb5c61a..7fd0b66c69b2 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -34,6 +34,9 @@ properties: - toradex,colibri_t20-iris - const: toradex,colibri_t20 - const: nvidia,tegra20 + - items: + - const: acer,picasso + - const: nvidia,tegra20 - items: - enum: - nvidia,beaver -- 2.26.0
[PATCH v7 3/6] dt-bindings: Add vendor prefix for Acer Inc.
Acer is a hardware and electronics corporation, specializing in advanced electronics technology. Acer's products include desktop PCs, laptop PCs, tablets, servers, displays, storage devices, virtual reality devices, smartphones and peripherals. Their web site is http://www.acer.com/. Signed-off-by: Dmitry Osipenko --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 334393037861..2c2ef989e273 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -27,6 +27,8 @@ patternProperties: description: Abilis Systems "^abracon,.*": description: Abracon Corporation + "^acer,.*": +description: Acer Inc. "^acme,.*": description: Acme Systems srl "^actions,.*": -- 2.26.0
[PATCH v7 5/6] dt-bindings: ARM: tegra: Add ASUS Google Nexus 7
Add a binding for the Tegra30-based ASUS Google Nexus 7 tablet device. Signed-off-by: Dmitry Osipenko --- Documentation/devicetree/bindings/arm/tegra.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 7fd0b66c69b2..fb3bbf7a5fb4 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -62,6 +62,13 @@ properties: - toradex,colibri_t30-eval-v3 - const: toradex,colibri_t30 - const: nvidia,tegra30 + - items: + - const: asus,grouper + - const: nvidia,tegra30 + - items: + - const: asus,tilapia + - const: asus,grouper + - const: nvidia,tegra30 - items: - enum: - nvidia,dalmore -- 2.26.0
Re: [PATCH 0/4] allow multiple kthreadd's
On Fri, May 01, 2020 at 02:21:54PM -0400, Tejun Heo wrote: > Hello, > > On Fri, May 01, 2020 at 10:59:24AM -0700, Linus Torvalds wrote: > > Which kind of makes me want to point a finger at Tejun. But it's been > > mostly PeterZ touching this file lately.. > > Looks fine to me too. I don't quite understand the usecase tho. It looks > like all it's being used for is to tag some kthreads as belonging to the > same group. Can't that be done with kthread_data()? Yeah, so I'd forgotten about kthread->data. We're currently using it to pass the struct svc_rqst that a new nfsd thread needs. But once the new thread has gotten that, I guess it could set kthread->data to some global value that it uses to say "I'm a knfsd thread"? I suppose that would work. Though now I'm feeling greedy: it would be nice to have both some kind of global flag, *and* keep kthread->data pointing to svc_rqst (as that would give me a simpler and quicker way to figure out which client is conflicting). Could I take a flag bit in kthread->flags, maybe? --b.
