Re: [PATCH 3/4] iio: light: stk3310: log error if reading the chip id fails
On Mon, 15 Apr 2024 18:05:54 +0300
Andy Shevchenko wrote:
> On Sun, Apr 14, 2024 at 8:57 PM Aren Moynihan wrote:
> >
> > If the chip isn't powered, this call is likely to return an error.
> > Without a log here the driver will silently fail to probe. Common errors
> > are ENXIO (when the chip isn't powered) and ETIMEDOUT (when the i2c bus
> > isn't powered).
>
> > ret = regmap_read(data->regmap, STK3310_REG_ID, );
> > - if (ret < 0)
> > + if (ret < 0) {
> > + dev_err(>dev, "failed to read chip id: %d", ret);
> > return ret;
> > + }
>
> Briefly looking at the code it seems that this one is strictly part of
> the probe phase, which means we may use
>
> return dev_err_probe(...);
>
> pattern. Yet, you may add another patch to clean up all of them:
> _probe(), _init(), _regmap_init() to use the same pattern everywhere.
>
Yes, a precursor patch to use dev_err_probe() throughout the probe only
functions in this driver would be excellent.
Jonathan
Re: [PATCH 1/4] dt-bindings: iio: light: stk33xx: add regulator for vdd supply
On Sun, 14 Apr 2024 13:57:13 -0400 Aren Moynihan wrote: > Signed-off-by: Aren Moynihan > --- > Documentation/devicetree/bindings/iio/light/stk33xx.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > index f6e22dc9814a..db35e239d4a8 100644 > --- a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > +++ b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > @@ -29,6 +29,7 @@ properties: >interrupts: > maxItems: 1 > > + vdd-supply: true As per review of patch 2, make it required and add one to the example. That doesn't mean it will be in every dts file, just that we expect it to exist given chips tend to work poorly without power. >proximity-near-level: true > > required:
Re: [PATCH 2/4] iio: light: stk3310: Implement vdd supply and power it off during suspend
On Sun, 14 Apr 2024 13:57:14 -0400
Aren Moynihan wrote:
> From: Ondrej Jirman
>
> VDD power input can be used to completely power off the chip during
> system suspend. Do so if available.
I'd make this non optional (relying on regulator framework providing
us a stub for old DT etc) and pay the minor cost of potentially restoring
registers when it was never powered down.
Simpler code and likely anyone who is doing suspend / resume will have
power control anyway.
Jonathan
>
> Signed-off-by: Ondrej Jirman
> Signed-off-by: Aren Moynihan
> ---
> drivers/iio/light/stk3310.c | 56 +++--
> 1 file changed, 53 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/light/stk3310.c b/drivers/iio/light/stk3310.c
> index 7b71ad71d78d..bfa090538df7 100644
> --- a/drivers/iio/light/stk3310.c
> +++ b/drivers/iio/light/stk3310.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #define STK3310_REG_STATE0x00
> #define STK3310_REG_PSCTRL 0x01
> @@ -117,6 +118,7 @@ struct stk3310_data {
> struct regmap_field *reg_int_ps;
> struct regmap_field *reg_flag_psint;
> struct regmap_field *reg_flag_nf;
> + struct regulator *vdd_reg;
> };
>
> static const struct iio_event_spec stk3310_events[] = {
> @@ -607,6 +609,16 @@ static int stk3310_probe(struct i2c_client *client)
>
> mutex_init(>lock);
>
> + data->vdd_reg = devm_regulator_get_optional(>dev, "vdd");
This needs a comment on why it is optional.
Generally power supply regulators are not, but I think the point here
is to avoid restoring the registers if the chip wasn't powered down?
This feels like an interesting gap in the regulator framework.
For most cases we can rely on stub / fake regulator being created
for always on supplies, but that doesn't let us elide the register writes.
My gut feeling is do them unconditionally. Suspend / resume isn't
that common that it will matter much.
That would allow you to have this as devm_regulator_get() and
drop handling of it not being provided.
> + if (IS_ERR(data->vdd_reg)) {
> + ret = PTR_ERR(data->vdd_reg);
> + if (ret == -ENODEV)
> + data->vdd_reg = NULL;
> + else
> + return dev_err_probe(>dev, ret,
> + "get regulator vdd failed\n");
> + }
> +
> ret = stk3310_regmap_init(data);
> if (ret < 0)
> return ret;
> @@ -617,9 +629,18 @@ static int stk3310_probe(struct i2c_client *client)
> indio_dev->channels = stk3310_channels;
> indio_dev->num_channels = ARRAY_SIZE(stk3310_channels);
>
> + if (data->vdd_reg) {
> + ret = regulator_enable(data->vdd_reg);
> + if (ret)
> + return dev_err_probe(>dev, ret,
> + "regulator vdd enable failed\n");
> +
> + usleep_range(1000, 2000);
> + }
> +
> ret = stk3310_init(indio_dev);
> if (ret < 0)
> - return ret;
> + goto err_vdd_disable;
>
> if (client->irq > 0) {
> ret = devm_request_threaded_irq(>dev, client->irq,
> @@ -645,32 +666,61 @@ static int stk3310_probe(struct i2c_client *client)
>
> err_standby:
> stk3310_set_state(data, STK3310_STATE_STANDBY);
> +err_vdd_disable:
> + if (data->vdd_reg)
> + regulator_disable(data->vdd_reg);
> return ret;
> }
>
> static void stk3310_remove(struct i2c_client *client)
> {
> struct iio_dev *indio_dev = i2c_get_clientdata(client);
> + struct stk3310_data *data = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> stk3310_set_state(iio_priv(indio_dev), STK3310_STATE_STANDBY);
> + if (data->vdd_reg)
> + regulator_disable(data->vdd_reg);
> }
>
> static int stk3310_suspend(struct device *dev)
> {
> struct stk3310_data *data;
> + int ret;
>
> data = iio_priv(i2c_get_clientdata(to_i2c_client(dev)));
>
> - return stk3310_set_state(data, STK3310_STATE_STANDBY);
> + ret = stk3310_set_state(data, STK3310_STATE_STANDBY);
> + if (ret)
> + return ret;
> +
> + if (data->vdd_reg) {
As above, I don't think we care enough about overhead on
boards where there isn't a vdd regulator. Just do this
unconditionally.
> + regcache_mark_dirty(data->regmap);
> + regulator_disable(data->vdd_reg);
> + }
> +
> + return 0;
> }
>
> static int stk3310_resume(struct device *dev)
> {
> - u8 state = 0;
> struct stk3310_data *data;
> + u8 state = 0;
> + int ret;
>
> data = iio_priv(i2c_get_clientdata(to_i2c_client(dev)));
> +
> + if (data->vdd_reg) {
> + ret = regulator_enable(data->vdd_reg);
> + if (ret) {
> + dev_err(dev, "Failed to re-enable regulator vdd\n");
> +
Re: [PATCH v11 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info
On Fri, 5 Apr 2024 00:07:06 + "Ho-Ren (Jack) Chuang" wrote: > The current implementation treats emulated memory devices, such as > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory > (E820_TYPE_RAM). However, these emulated devices have different > characteristics than traditional DRAM, making it important to > distinguish them. Thus, we modify the tiered memory initialization process > to introduce a delay specifically for CPUless NUMA nodes. This delay > ensures that the memory tier initialization for these nodes is deferred > until HMAT information is obtained during the boot process. Finally, > demotion tables are recalculated at the end. > > * late_initcall(memory_tier_late_init); > Some device drivers may have initialized memory tiers between > `memory_tier_init()` and `memory_tier_late_init()`, potentially bringing > online memory nodes and configuring memory tiers. They should be excluded > in the late init. > > * Handle cases where there is no HMAT when creating memory tiers > There is a scenario where a CPUless node does not provide HMAT information. > If no HMAT is specified, it falls back to using the default DRAM tier. > > * Introduce another new lock `default_dram_perf_lock` for adist calculation > In the current implementation, iterating through CPUlist nodes requires > holding the `memory_tier_lock`. However, `mt_calc_adistance()` will end up > trying to acquire the same lock, leading to a potential deadlock. > Therefore, we propose introducing a standalone `default_dram_perf_lock` to > protect `default_dram_perf_*`. This approach not only avoids deadlock > but also prevents holding a large lock simultaneously. > > * Upgrade `set_node_memory_tier` to support additional cases, including > default DRAM, late CPUless, and hot-plugged initializations. > To cover hot-plugged memory nodes, `mt_calc_adistance()` and > `mt_find_alloc_memory_type()` are moved into `set_node_memory_tier()` to > handle cases where memtype is not initialized and where HMAT information is > available. > > * Introduce `default_memory_types` for those memory types that are not > initialized by device drivers. > Because late initialized memory and default DRAM memory need to be managed, > a default memory type is created for storing all memory types that are > not initialized by device drivers and as a fallback. > > Signed-off-by: Ho-Ren (Jack) Chuang > Signed-off-by: Hao Xiang > Reviewed-by: "Huang, Ying" Reviewed-by: Jonathan Cameron
Re: [PATCH] dt-bindings: iio: imu: mpu6050: Improve i2c-gate disallow list
On Tue, 9 Apr 2024 08:36:08 +0200
Krzysztof Kozlowski wrote:
> On 08/04/2024 18:34, Luca Weiss wrote:
> > Before all supported sensors except for MPU{9150,9250,9255} were not
> > allowed to use i2c-gate in the bindings which excluded quite a few
> > supported sensors where this functionality is supported.
> >
> > Switch the list of sensors to ones where the Linux driver explicitly
> > disallows support for the auxiliary bus ("inv_mpu_i2c_aux_bus"). Since
> > the driver is also based on "default: return true" this should scale
> > better into the future.
> >
> > Signed-off-by: Luca Weiss
>
> Acked-by: Krzysztof Kozlowski
>
> Best regards,
> Krzysztof
>
Applied, thanks
Re: [External] Re: [PATCH v11 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info
On Tue, 9 Apr 2024 12:02:31 -0700 "Ho-Ren (Jack) Chuang" wrote: > Hi Jonathan, > > On Tue, Apr 9, 2024 at 9:12 AM Jonathan Cameron > wrote: > > > > On Fri, 5 Apr 2024 15:43:47 -0700 > > "Ho-Ren (Jack) Chuang" wrote: > > > > > On Fri, Apr 5, 2024 at 7:03 AM Jonathan Cameron > > > wrote: > > > > > > > > On Fri, 5 Apr 2024 00:07:06 + > > > > "Ho-Ren (Jack) Chuang" wrote: > > > > > > > > > The current implementation treats emulated memory devices, such as > > > > > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal > > > > > memory > > > > > (E820_TYPE_RAM). However, these emulated devices have different > > > > > characteristics than traditional DRAM, making it important to > > > > > distinguish them. Thus, we modify the tiered memory initialization > > > > > process > > > > > to introduce a delay specifically for CPUless NUMA nodes. This delay > > > > > ensures that the memory tier initialization for these nodes is > > > > > deferred > > > > > until HMAT information is obtained during the boot process. Finally, > > > > > demotion tables are recalculated at the end. > > > > > > > > > > * late_initcall(memory_tier_late_init); > > > > > Some device drivers may have initialized memory tiers between > > > > > `memory_tier_init()` and `memory_tier_late_init()`, potentially > > > > > bringing > > > > > online memory nodes and configuring memory tiers. They should be > > > > > excluded > > > > > in the late init. > > > > > > > > > > * Handle cases where there is no HMAT when creating memory tiers > > > > > There is a scenario where a CPUless node does not provide HMAT > > > > > information. > > > > > If no HMAT is specified, it falls back to using the default DRAM tier. > > > > > > > > > > * Introduce another new lock `default_dram_perf_lock` for adist > > > > > calculation > > > > > In the current implementation, iterating through CPUlist nodes > > > > > requires > > > > > holding the `memory_tier_lock`. However, `mt_calc_adistance()` will > > > > > end up > > > > > trying to acquire the same lock, leading to a potential deadlock. > > > > > Therefore, we propose introducing a standalone > > > > > `default_dram_perf_lock` to > > > > > protect `default_dram_perf_*`. This approach not only avoids deadlock > > > > > but also prevents holding a large lock simultaneously. > > > > > > > > > > * Upgrade `set_node_memory_tier` to support additional cases, > > > > > including > > > > > default DRAM, late CPUless, and hot-plugged initializations. > > > > > To cover hot-plugged memory nodes, `mt_calc_adistance()` and > > > > > `mt_find_alloc_memory_type()` are moved into `set_node_memory_tier()` > > > > > to > > > > > handle cases where memtype is not initialized and where HMAT > > > > > information is > > > > > available. > > > > > > > > > > * Introduce `default_memory_types` for those memory types that are not > > > > > initialized by device drivers. > > > > > Because late initialized memory and default DRAM memory need to be > > > > > managed, > > > > > a default memory type is created for storing all memory types that are > > > > > not initialized by device drivers and as a fallback. > > > > > > > > > > Signed-off-by: Ho-Ren (Jack) Chuang > > > > > Signed-off-by: Hao Xiang > > > > > Reviewed-by: "Huang, Ying" > > > > > > > > Hi - one remaining question. Why can't we delay init for all nodes > > > > to either drivers or your fallback late_initcall code. > > > > It would be nice to reduce possible code paths. > > > > > > I try not to change too much of the existing code structure in > > > this patchset. > > > > > > To me, postponing/moving all memory tier registrations to > > > late_initcall() is another possible action item for the next patchset. > > > > > > After tier_mem(), hmat_init() is called, which requires registering > > > `default_dram_type` info. This is when `default_dram_type` is needed. > > > However, it is indeed possible to postpone the latter part, > > > set_node_memory_tier(), to `late_init(). So, memory_tier_init() can > > > indeed be split into two parts, and the latter part can be moved to > > > late_initcall() to be processed together. > > > > > > Doing this all memory-type drivers have to call late_initcall() to > > > register a memory tier. I’m not sure how many they are? > > > > > > What do you guys think? > > > > Gut feeling - if you are going to move it for some cases, move it for > > all of them. Then we only have to test once ;) > > > > J > > Thank you for your reminder! I agree~ That's why I'm considering > changing them in the next patchset because of the amount of changes. > And also, this patchset already contains too many things. Makes sense. (Interestingly we are reaching the same conclusion for the thread that motivated suggesting bringing them all together in the first place!) Get things work in a clean fashion, then consider moving everything to happen at the same time to simplify testing etc. Jonathan
Re: [PATCH v11 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info
On Fri, 5 Apr 2024 15:43:47 -0700 "Ho-Ren (Jack) Chuang" wrote: > On Fri, Apr 5, 2024 at 7:03 AM Jonathan Cameron > wrote: > > > > On Fri, 5 Apr 2024 00:07:06 + > > "Ho-Ren (Jack) Chuang" wrote: > > > > > The current implementation treats emulated memory devices, such as > > > CXL1.1 type3 memory, as normal DRAM when they are emulated as normal > > > memory > > > (E820_TYPE_RAM). However, these emulated devices have different > > > characteristics than traditional DRAM, making it important to > > > distinguish them. Thus, we modify the tiered memory initialization process > > > to introduce a delay specifically for CPUless NUMA nodes. This delay > > > ensures that the memory tier initialization for these nodes is deferred > > > until HMAT information is obtained during the boot process. Finally, > > > demotion tables are recalculated at the end. > > > > > > * late_initcall(memory_tier_late_init); > > > Some device drivers may have initialized memory tiers between > > > `memory_tier_init()` and `memory_tier_late_init()`, potentially bringing > > > online memory nodes and configuring memory tiers. They should be excluded > > > in the late init. > > > > > > * Handle cases where there is no HMAT when creating memory tiers > > > There is a scenario where a CPUless node does not provide HMAT > > > information. > > > If no HMAT is specified, it falls back to using the default DRAM tier. > > > > > > * Introduce another new lock `default_dram_perf_lock` for adist > > > calculation > > > In the current implementation, iterating through CPUlist nodes requires > > > holding the `memory_tier_lock`. However, `mt_calc_adistance()` will end up > > > trying to acquire the same lock, leading to a potential deadlock. > > > Therefore, we propose introducing a standalone `default_dram_perf_lock` to > > > protect `default_dram_perf_*`. This approach not only avoids deadlock > > > but also prevents holding a large lock simultaneously. > > > > > > * Upgrade `set_node_memory_tier` to support additional cases, including > > > default DRAM, late CPUless, and hot-plugged initializations. > > > To cover hot-plugged memory nodes, `mt_calc_adistance()` and > > > `mt_find_alloc_memory_type()` are moved into `set_node_memory_tier()` to > > > handle cases where memtype is not initialized and where HMAT information > > > is > > > available. > > > > > > * Introduce `default_memory_types` for those memory types that are not > > > initialized by device drivers. > > > Because late initialized memory and default DRAM memory need to be > > > managed, > > > a default memory type is created for storing all memory types that are > > > not initialized by device drivers and as a fallback. > > > > > > Signed-off-by: Ho-Ren (Jack) Chuang > > > Signed-off-by: Hao Xiang > > > Reviewed-by: "Huang, Ying" > > > > Hi - one remaining question. Why can't we delay init for all nodes > > to either drivers or your fallback late_initcall code. > > It would be nice to reduce possible code paths. > > I try not to change too much of the existing code structure in > this patchset. > > To me, postponing/moving all memory tier registrations to > late_initcall() is another possible action item for the next patchset. > > After tier_mem(), hmat_init() is called, which requires registering > `default_dram_type` info. This is when `default_dram_type` is needed. > However, it is indeed possible to postpone the latter part, > set_node_memory_tier(), to `late_init(). So, memory_tier_init() can > indeed be split into two parts, and the latter part can be moved to > late_initcall() to be processed together. > > Doing this all memory-type drivers have to call late_initcall() to > register a memory tier. I’m not sure how many they are? > > What do you guys think? Gut feeling - if you are going to move it for some cases, move it for all of them. Then we only have to test once ;) J > > > > > Jonathan > > > > > > > --- > > > mm/memory-tiers.c | 94 +++ > > > 1 file changed, 70 insertions(+), 24 deletions(-) > > > > > > diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c > > > index 516b144fd45a..6632102bd5c9 100644 > > > --- a/mm/memory-tiers.c > > > +++ b/mm/memory-tiers.c > > > >
Re: [PATCH] Documentation: ABI: document in_temp_input file
On Sat, 06 Apr 2024 17:31:04 +0200 Luca Weiss wrote: > For example the BMP280 barometric pressure sensor on Qualcomm > MSM8974-based Nexus 5 smartphone exposes such file in sysfs. > Document it. > > Signed-off-by: Luca Weiss Hi Luca, Applied with a note added on fixing the line above to not reuse X. A good additional thing but needs mentioning in the commit message. Thanks, Jonathan > --- > Documentation/ABI/testing/sysfs-bus-iio | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio > b/Documentation/ABI/testing/sysfs-bus-iio > index 2e6d5ebfd3c7..7cee78ad4108 100644 > --- a/Documentation/ABI/testing/sysfs-bus-iio > +++ b/Documentation/ABI/testing/sysfs-bus-iio > @@ -243,7 +243,8 @@ Description: > less measurements. Units after application of scale and offset > are milli degrees Celsius. > > -What:/sys/bus/iio/devices/iio:deviceX/in_tempX_input > +What:/sys/bus/iio/devices/iio:deviceX/in_tempY_input > +What:/sys/bus/iio/devices/iio:deviceX/in_temp_input > KernelVersion: 2.6.38 > Contact: linux-...@vger.kernel.org > Description: > > --- > base-commit: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc > change-id: 20240406-in_temp_input-4505d7fafff8 > > Best regards,
Re: [PATCH v11 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info
On Fri, 5 Apr 2024 00:07:06 +
"Ho-Ren (Jack) Chuang" wrote:
> The current implementation treats emulated memory devices, such as
> CXL1.1 type3 memory, as normal DRAM when they are emulated as normal memory
> (E820_TYPE_RAM). However, these emulated devices have different
> characteristics than traditional DRAM, making it important to
> distinguish them. Thus, we modify the tiered memory initialization process
> to introduce a delay specifically for CPUless NUMA nodes. This delay
> ensures that the memory tier initialization for these nodes is deferred
> until HMAT information is obtained during the boot process. Finally,
> demotion tables are recalculated at the end.
>
> * late_initcall(memory_tier_late_init);
> Some device drivers may have initialized memory tiers between
> `memory_tier_init()` and `memory_tier_late_init()`, potentially bringing
> online memory nodes and configuring memory tiers. They should be excluded
> in the late init.
>
> * Handle cases where there is no HMAT when creating memory tiers
> There is a scenario where a CPUless node does not provide HMAT information.
> If no HMAT is specified, it falls back to using the default DRAM tier.
>
> * Introduce another new lock `default_dram_perf_lock` for adist calculation
> In the current implementation, iterating through CPUlist nodes requires
> holding the `memory_tier_lock`. However, `mt_calc_adistance()` will end up
> trying to acquire the same lock, leading to a potential deadlock.
> Therefore, we propose introducing a standalone `default_dram_perf_lock` to
> protect `default_dram_perf_*`. This approach not only avoids deadlock
> but also prevents holding a large lock simultaneously.
>
> * Upgrade `set_node_memory_tier` to support additional cases, including
> default DRAM, late CPUless, and hot-plugged initializations.
> To cover hot-plugged memory nodes, `mt_calc_adistance()` and
> `mt_find_alloc_memory_type()` are moved into `set_node_memory_tier()` to
> handle cases where memtype is not initialized and where HMAT information is
> available.
>
> * Introduce `default_memory_types` for those memory types that are not
> initialized by device drivers.
> Because late initialized memory and default DRAM memory need to be managed,
> a default memory type is created for storing all memory types that are
> not initialized by device drivers and as a fallback.
>
> Signed-off-by: Ho-Ren (Jack) Chuang
> Signed-off-by: Hao Xiang
> Reviewed-by: "Huang, Ying"
Hi - one remaining question. Why can't we delay init for all nodes
to either drivers or your fallback late_initcall code.
It would be nice to reduce possible code paths.
Jonathan
> ---
> mm/memory-tiers.c | 94 +++
> 1 file changed, 70 insertions(+), 24 deletions(-)
>
> diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c
> index 516b144fd45a..6632102bd5c9 100644
> --- a/mm/memory-tiers.c
> +++ b/mm/memory-tiers.c
> @@ -855,7 +892,8 @@ static int __init memory_tier_init(void)
>* For now we can have 4 faster memory tiers with smaller adistance
>* than default DRAM tier.
>*/
> - default_dram_type = alloc_memory_type(MEMTIER_ADISTANCE_DRAM);
> + default_dram_type = mt_find_alloc_memory_type(MEMTIER_ADISTANCE_DRAM,
> + _memory_types);
> if (IS_ERR(default_dram_type))
> panic("%s() failed to allocate default DRAM tier\n", __func__);
>
> @@ -865,6 +903,14 @@ static int __init memory_tier_init(void)
>* types assigned.
>*/
> for_each_node_state(node, N_MEMORY) {
> + if (!node_state(node, N_CPU))
> + /*
> + * Defer memory tier initialization on
> + * CPUless numa nodes. These will be initialized
> + * after firmware and devices are initialized.
Could the comment also say why we can't defer them all?
(In an odd coincidence we have a similar issue for some CPU hotplug
related bring up where review feedback was move all cases later).
> + */
> + continue;
> +
> memtier = set_node_memory_tier(node);
> if (IS_ERR(memtier))
> /*
Re: [PATCH v11 1/2] memory tier: dax/kmem: introduce an abstract layer for finding, allocating, and putting memory types
On Fri, 5 Apr 2024 00:07:05 + "Ho-Ren (Jack) Chuang" wrote: > Since different memory devices require finding, allocating, and putting > memory types, these common steps are abstracted in this patch, > enhancing the scalability and conciseness of the code. > > Signed-off-by: Ho-Ren (Jack) Chuang > Reviewed-by: "Huang, Ying" Reviewed-by: Jonathan Cameron
Re: [PATCH v10 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info
> > > @@ -858,7 +910,8 @@ static int __init memory_tier_init(void)
> > >* For now we can have 4 faster memory tiers with smaller adistance
> > >* than default DRAM tier.
> > >*/
> > > - default_dram_type = alloc_memory_type(MEMTIER_ADISTANCE_DRAM);
> > > + default_dram_type =
> > > mt_find_alloc_memory_type(MEMTIER_ADISTANCE_DRAM,
> > > +
> > > _memory_types);
> >
> > Unusual indenting. Align with just after (
> >
>
> Aligning with "(" will exceed 100 columns. Would that be acceptable?
I think we are talking cross purposes.
default_dram_type = mt_find_alloc_memory_type(MEMTIER_ADISTANCE_DRAM,
_memory_types);
Is what I was suggesting.
>
> > > if (IS_ERR(default_dram_type))
> > > panic("%s() failed to allocate default DRAM tier\n",
> > > __func__);
> > >
> > > @@ -868,6 +921,14 @@ static int __init memory_tier_init(void)
> > >* types assigned.
> > >*/
> > > for_each_node_state(node, N_MEMORY) {
> > > + if (!node_state(node, N_CPU))
> > > + /*
> > > + * Defer memory tier initialization on CPUless numa
> > > nodes.
> > > + * These will be initialized after firmware and
> > > devices are
> >
> > I think this wraps at just over 80 chars. Seems silly to wrap so tightly
> > and not
> > quite fit under 80. (this is about 83 chars.
> >
>
> I can fix this.
> I have a question. From my patch, this is <80 chars. However,
> in an email, this is >80 chars. Does that mean we need to
> count the number of chars in an email, not in a patch? Or if I
> missed something? like vim configuration or?
3 tabs + 1 space + the text from * (58)
= 24 + 1 + 58 = 83
Advantage of using claws email for kernel stuff is it has a nice per character
ruler at the top of the window.
I wonder if you have a different tab indent size? The kernel uses 8
characters. It might explain the few other odd indents if perhaps
you have it at 4 in your editor?
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
Jonathan
>
> > > + * initialized.
> > > + */
> > > + continue;
> > > +
> > > memtier = set_node_memory_tier(node);
> > > if (IS_ERR(memtier))
> > > /*
> >
>
>
Re: [PATCH v10 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info
A few minor comments inline.
> diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h
> index a44c03c2ba3a..16769552a338 100644
> --- a/include/linux/memory-tiers.h
> +++ b/include/linux/memory-tiers.h
> @@ -140,12 +140,13 @@ static inline int mt_perf_to_adistance(struct
> access_coordinate *perf, int *adis
> return -EIO;
> }
>
> -struct memory_dev_type *mt_find_alloc_memory_type(int adist, struct
> list_head *memory_types)
> +static inline struct memory_dev_type *mt_find_alloc_memory_type(int adist,
> + struct list_head *memory_types)
> {
> return NULL;
> }
>
> -void mt_put_memory_types(struct list_head *memory_types)
> +static inline void mt_put_memory_types(struct list_head *memory_types)
> {
Why in this patch and not previous one?
>
> }
> diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c
> index 974af10cfdd8..44fa10980d37 100644
> --- a/mm/memory-tiers.c
> +++ b/mm/memory-tiers.c
> @@ -36,6 +36,11 @@ struct node_memory_type_map {
>
> static DEFINE_MUTEX(memory_tier_lock);
> static LIST_HEAD(memory_tiers);
> +/*
> + * The list is used to store all memory types that are not created
> + * by a device driver.
> + */
> +static LIST_HEAD(default_memory_types);
> static struct node_memory_type_map node_memory_types[MAX_NUMNODES];
> struct memory_dev_type *default_dram_type;
>
> @@ -108,6 +113,8 @@ static struct demotion_nodes *node_demotion __read_mostly;
>
> static BLOCKING_NOTIFIER_HEAD(mt_adistance_algorithms);
>
> +/* The lock is used to protect `default_dram_perf*` info and nid. */
> +static DEFINE_MUTEX(default_dram_perf_lock);
> static bool default_dram_perf_error;
> static struct access_coordinate default_dram_perf;
> static int default_dram_perf_ref_nid = NUMA_NO_NODE;
> @@ -505,7 +512,8 @@ static inline void __init_node_memory_type(int node,
> struct memory_dev_type *mem
> static struct memory_tier *set_node_memory_tier(int node)
> {
> struct memory_tier *memtier;
> - struct memory_dev_type *memtype;
> + struct memory_dev_type *mtype = default_dram_type;
Does the rename add anything major to the patch?
If not I'd leave it alone to reduce the churn and give
a more readable patch. If it is worth doing perhaps
a precursor patch?
> + int adist = MEMTIER_ADISTANCE_DRAM;
> pg_data_t *pgdat = NODE_DATA(node);
>
>
> @@ -514,11 +522,20 @@ static struct memory_tier *set_node_memory_tier(int
> node)
> if (!node_state(node, N_MEMORY))
> return ERR_PTR(-EINVAL);
>
> - __init_node_memory_type(node, default_dram_type);
> + mt_calc_adistance(node, );
> + if (node_memory_types[node].memtype == NULL) {
> + mtype = mt_find_alloc_memory_type(adist, _memory_types);
> + if (IS_ERR(mtype)) {
> + mtype = default_dram_type;
> + pr_info("Failed to allocate a memory type. Fall
> back.\n");
> + }
> + }
> +
> + __init_node_memory_type(node, mtype);
>
> - memtype = node_memory_types[node].memtype;
> - node_set(node, memtype->nodes);
> - memtier = find_create_memory_tier(memtype);
> + mtype = node_memory_types[node].memtype;
> + node_set(node, mtype->nodes);
> + memtier = find_create_memory_tier(mtype);
> if (!IS_ERR(memtier))
> rcu_assign_pointer(pgdat->memtier, memtier);
> return memtier;
> @@ -655,6 +672,33 @@ void mt_put_memory_types(struct list_head *memory_types)
> }
> EXPORT_SYMBOL_GPL(mt_put_memory_types);
>
> +/*
> + * This is invoked via `late_initcall()` to initialize memory tiers for
> + * CPU-less memory nodes after driver initialization, which is
> + * expected to provide `adistance` algorithms.
> + */
> +static int __init memory_tier_late_init(void)
> +{
> + int nid;
> +
> + mutex_lock(_tier_lock);
> + for_each_node_state(nid, N_MEMORY)
> + if (node_memory_types[nid].memtype == NULL)
> + /*
> + * Some device drivers may have initialized memory tiers
> + * between `memory_tier_init()` and
> `memory_tier_late_init()`,
> + * potentially bringing online memory nodes and
> + * configuring memory tiers. Exclude them here.
> + */
Does the comment refer to this path, or to ones where memtype is set?
> + set_node_memory_tier(nid);
Given the large comment I would add {} to help with readability.
You could flip the logic to reduce indent
for_each_node_state(nid, N_MEMORY) {
if (node_memory_types[nid].memtype)
continue;
/*
* Some device drivers may have initialized memory tiers
* between `memory_tier_init()` and `memory_tier_late_init()`,
* potentially bringing online memory nodes and
* configuring memory tiers. Exclude them
Re: [PATCH v10 1/2] memory tier: dax/kmem: introduce an abstract layer for finding, allocating, and putting memory types
On Tue, 2 Apr 2024 00:17:37 +
"Ho-Ren (Jack) Chuang" wrote:
> Since different memory devices require finding, allocating, and putting
> memory types, these common steps are abstracted in this patch,
> enhancing the scalability and conciseness of the code.
>
> Signed-off-by: Ho-Ren (Jack) Chuang
> Reviewed-by: "Huang, Ying"
Hi,
I know this is a late entry to the discussion but a few comments inline.
(sorry I didn't look earlier!)
All opportunities to improve code complexity and readability as a result
of your factoring out.
Jonathan
> ---
> drivers/dax/kmem.c | 20 ++--
> include/linux/memory-tiers.h | 13 +
> mm/memory-tiers.c| 32
> 3 files changed, 47 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index 42ee360cf4e3..01399e5b53b2 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers/dax/kmem.c
> @@ -55,21 +55,10 @@ static LIST_HEAD(kmem_memory_types);
>
> static struct memory_dev_type *kmem_find_alloc_memory_type(int adist)
> {
> - bool found = false;
> struct memory_dev_type *mtype;
>
> mutex_lock(_memory_type_lock);
could use
guard(mutex)(_memory_type_lock);
return mt_find_alloc_memory_type(adist, _memory_types);
I'm fine if you ignore this comment though as may be other functions in
here that could take advantage of the cleanup.h stuff in a future patch.
> - list_for_each_entry(mtype, _memory_types, list) {
> - if (mtype->adistance == adist) {
> - found = true;
> - break;
> - }
> - }
> - if (!found) {
> - mtype = alloc_memory_type(adist);
> - if (!IS_ERR(mtype))
> - list_add(>list, _memory_types);
> - }
> + mtype = mt_find_alloc_memory_type(adist, _memory_types);
> mutex_unlock(_memory_type_lock);
>
> return mtype;
> diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h
> index 69e781900082..a44c03c2ba3a 100644
> --- a/include/linux/memory-tiers.h
> +++ b/include/linux/memory-tiers.h
> @@ -48,6 +48,9 @@ int mt_calc_adistance(int node, int *adist);
> int mt_set_default_dram_perf(int nid, struct access_coordinate *perf,
>const char *source);
> int mt_perf_to_adistance(struct access_coordinate *perf, int *adist);
> +struct memory_dev_type *mt_find_alloc_memory_type(int adist,
> + struct list_head
> *memory_types);
That indent looks unusual. Align the start of struct with start of int.
> +void mt_put_memory_types(struct list_head *memory_types);
> #ifdef CONFIG_MIGRATION
> int next_demotion_node(int node);
> void node_get_allowed_targets(pg_data_t *pgdat, nodemask_t *targets);
> @@ -136,5 +139,15 @@ static inline int mt_perf_to_adistance(struct
> access_coordinate *perf, int *adis
> {
> return -EIO;
> }
> +
> +struct memory_dev_type *mt_find_alloc_memory_type(int adist, struct
> list_head *memory_types)
> +{
> + return NULL;
> +}
> +
> +void mt_put_memory_types(struct list_head *memory_types)
> +{
> +
No blank line needed here.
> +}
> #endif /* CONFIG_NUMA */
> #endif /* _LINUX_MEMORY_TIERS_H */
> diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c
> index 0537664620e5..974af10cfdd8 100644
> --- a/mm/memory-tiers.c
> +++ b/mm/memory-tiers.c
> @@ -623,6 +623,38 @@ void clear_node_memory_type(int node, struct
> memory_dev_type *memtype)
> }
> EXPORT_SYMBOL_GPL(clear_node_memory_type);
>
> +struct memory_dev_type *mt_find_alloc_memory_type(int adist, struct
> list_head *memory_types)
Breaking this out as a separate function provides opportunity to improve it.
Maybe a follow up patch makes sense given it would no longer be a straight
forward code move. However in my view it would be simple enough to be obvious
even within this patch.
> +{
> + bool found = false;
> + struct memory_dev_type *mtype;
> +
> + list_for_each_entry(mtype, memory_types, list) {
> + if (mtype->adistance == adist) {
> + found = true;
Why not return here?
return mtype;
> + break;
> + }
> + }
> + if (!found) {
If returning above, no need for found variable - just do this unconditionally.
+ I suggest you flip logic for simpler to follow code flow.
It's more code but I think a bit easier to read as error handling is
out of the main simple flow.
mtype = alloc_memory_type(adist);
if (IS_ERR(mtype))
return mtype;
list_add(>list, memory_types);
return mtype;
> + mtype = alloc_memory_type(adist);
> + if (!IS_ERR(mtype))
> + list_add(>list, memory_types);
> + }
> +
> + return mtype;
> +}
> +EXPORT_SYMBOL_GPL(mt_find_alloc_memory_type);
> +
> +void mt_put_memory_types(struct
Re: [PATCH v2] acpi/ghes: Prevent sleeping with spinlock held
On Wed, 14 Feb 2024 17:33:18 -0500 Steven Rostedt wrote: > On Wed, 14 Feb 2024 14:19:19 -0800 > Ira Weiny wrote: > > > > > Jonathan Cameron wrote: > > > > > > > > > So I'm thinking this is a won't fix - wait for the printk rework to > > > > > land and > > > > > assume this will be resolved as well? > > > > > > > > That pretty much sums up what I was about to say ;-) > > > > > > > > tp_printk is more of a hack and not to be used sparingly. With the right > > > > trace events it can hang the machine. > > > > > > > > So, you can use your internal patch locally, but I would recommend > > > > waiting > > > > for the new printk changes to land. > > > > Steven, Do you think that will land in 6.9? > > > > > > > > > > I'm really hoping that will be soon! > > > > > > I may be like Jon Corbet predicting RT will land in mainline if I do. > > -- Steve > Agreed. Don't wait on printk fixes landing. (Well unless you are sure it's the year of the Linux desktop.) Reverting is fine for 6.8 if you and Dan feel it's unwise to take this forwards (all the distros will backport it anyway and 6.8 isn't an LTS so no great rush) so fine to just queue it up again for 6.9 with this fix. As Steve said, tp_printk is a hack (a very useful one) and hopefully no one runs it in production. Jonathan
Re: [PATCH v2] acpi/ghes: Prevent sleeping with spinlock held
On Wed, 14 Feb 2024 10:23:10 -0500 Steven Rostedt wrote: > On Wed, 14 Feb 2024 12:11:53 + > Jonathan Cameron wrote: > > > So I'm thinking this is a won't fix - wait for the printk rework to land and > > assume this will be resolved as well? > > That pretty much sums up what I was about to say ;-) > > tp_printk is more of a hack and not to be used sparingly. With the right > trace events it can hang the machine. > > So, you can use your internal patch locally, but I would recommend waiting > for the new printk changes to land. I'm really hoping that will be soon! > > -- Steve Thanks Steve, Ira's fix is needed for other valid locking reasons - this was 'just another' lock debugging report that came up whilst testing it. For this patch (not a potential additional one that we aren't going to do ;) Tested-by: Jonathan Cameron Reviewed-by: Jonathan Cameron
Re: [PATCH v2] acpi/ghes: Prevent sleeping with spinlock held
On Tue, 06 Feb 2024 14:15:32 -0800
Ira Weiny wrote:
> Smatch caught that cxl_cper_post_event() is called with a spinlock held
> or preemption disabled.[1] The callback takes the device lock to
> perform address translation and therefore might sleep. The record data
> is released back to BIOS in ghes_clear_estatus() which requires it to be
> copied for use in the workqueue.
>
> Copy the record to a lockless list and schedule a work item to process
> the record outside of atomic context.
>
> [1]
> https://lore.kernel.org/all/b963c490-2c13-4b79-bbe7-34c6568423c7@moroto.mountain/
>
> Reported-by: Dan Carpenter
> Signed-off-by: Ira Weiny
+CC tracing folk for the splat below (the second one as first one is fixed!)
Lock debugging is slow (on an emulated machine) :(
Testing with my gitlab.com/jic23/qemu cxl-2024-02-05-draft branch
which is only one I've put out with the FW first injection patches so far
For reference without this patch I got a nice spat identifying the original bug.
So far so good.
With this patch (and tp_printk in command line and trace points enabled)
[ 193.048229] {1}[Hardware Error]: Hardware error from APEI Generic Hardware
Error Source: 1
[ 193.049636] {1}[Hardware Error]: event severity: recoverable
[ 193.050472] {1}[Hardware Error]: Error 0, type: recoverable
[ 193.051337] {1}[Hardware Error]: section type: unknown,
fbcd0a77-c260-417f-85a9-088b1621eba6
[ 193.052270] {1}[Hardware Error]: section length: 0x90
[ 193.053402] {1}[Hardware Error]: : 0090 0007
0d938086
[ 193.055036] {1}[Hardware Error]: 0010: 000e 0005
[ 193.058592] {1}[Hardware Error]: 0020: 0180 1626fa24
17b3b158 $.&.X...
[ 193.062289] {1}[Hardware Error]: 0030:
[ 193.065959] {1}[Hardware Error]: 0040: 07d0 0fc00307
05210300 ..!.
[ 193.069782] {1}[Hardware Error]: 0050: 7269 6d207361 00326d65
..iras mem2.
[ 193.072760] {1}[Hardware Error]: 0060:
[ 193.074062] {1}[Hardware Error]: 0070:
[ 193.075346] {1}[Hardware Error]: 0080:
I rebased after this so now we get the smaller print - but that's not really
relevant here.
[ 193.086589] cxl_general_media: memdev=mem1 host=:0e:00.0 serial=5
log=Warning : time=1707903675590441508
uuid=fbcd0a77-c260-417f-85a9-088b1621eba6 len=128 flags='0x1' handle=0
related_handle=0 maint_op_class=0 : dpa=7c0 dpa_flags='0x10'
descriptor='UNCORRECTABLE_EVENT|THRESHOLD_EVENT|POISON_LIST_OVERFLOW'
type='0x3' transaction_type='0xc0' channel=3 rank=33 device=5 comp_id=69 72 61
73 20 6d 65 6d 32 00 00 00 00 00 00 00
validity_flags='CHANNEL|RANK|DEVICE|COMPONENT'
[ 193.087181]
[ 193.087361] =
[ 193.087399] [ BUG: Invalid wait context ]
[ 193.087504] 6.8.0-rc3 #1200 Not tainted
[ 193.087660] -
[ 193.087858] kworker/3:0/31 is trying to lock:
[ 193.087966] c0ce1898 (_lock_key){-.-.}-{3:3}, at:
pl011_console_write+0x148/0x1c8
[ 193.089754] other info that might help us debug this:
[ 193.089820] context-{5:5}[ 193.089900] 8 locks held by kworker/3:0/31:
[ 193.089990] #0: c0018738 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x154/0x500
[ 193.090439] #1: 800083793de0 (cxl_cper_work){+.+.}-{0:0}, at:
process_one_work+0x154/0x500
[ 193.090718] #2: 800082883310 (cxl_cper_rw_sem){}-{4:4}, at:
cxl_cper_work_fn+0x2c/0xb0
[ 193.091019] #3: c0a7b1a8 (>mutex){}-{4:4}, at:
pci_dev_lock+0x28/0x48
[ 193.091431] #4: 800082738f18 (tracepoint_iter_lock){}-{2:2}, at:
trace_event_buffer_commit+0xd8/0x2c8
[ 193.091772] #5: 8000826b3ce8 (console_lock){+.+.}-{0:0}, at:
vprintk_emit+0x124/0x398
[ 193.092031] #6: 8000826b3d40 (console_srcu){}-{0:0}, at:
console_flush_all+0x88/0x4b0
[ 193.092363] #7: 8000826b3ef8 (console_owner){}-{0:0}, at:
console_flush_all+0x1bc/0x4b0
[ 193.092799] stack backtrace:
[ 193.092973] CPU: 3 PID: 31 Comm: kworker/3:0 Not tainted 6.8.0-rc3 #1200
[ 193.093118] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown unknown
[ 193.093468] Workqueue: events cxl_cper_work_fn
[ 193.093782] Call trace:
[ 193.094004] dump_backtrace+0xa4/0x130
[ 193.094145] show_stack+0x20/0x38
[ 193.094231] dump_stack_lvl+0x60/0xb0
[ 193.094315] dump_stack+0x18/0x28
[ 193.094395] __lock_acquire+0x9e8/0x1ee8
[ 193.094477]
Re: [PATCH v6 2/4] dax/bus: Use guard(device) in sysfs attribute helpers
On Thu, 14 Dec 2023 22:25:27 -0700
Vishal Verma wrote:
> Use the guard(device) macro to lock a 'struct device', and unlock it
> automatically when going out of scope using Scope Based Resource
> Management semantics. A lot of the sysfs attribute writes in
> drivers/dax/bus.c benefit from a cleanup using these, so change these
> where applicable.
>
> Cc: Joao Martins
> Cc: Dan Williams
> Signed-off-by: Vishal Verma
Hi Vishal,
A few really minor suggestions inline if you happen to be doing a v7.
Either way
Reviewed-by: Jonathan Cameron
>
> @@ -481,12 +466,9 @@ static int __free_dev_dax_id(struct dev_dax *dev_dax)
> static int free_dev_dax_id(struct dev_dax *dev_dax)
> {
> struct device *dev = _dax->dev;
> - int rc;
>
> - device_lock(dev);
> - rc = __free_dev_dax_id(dev_dax);
> - device_unlock(dev);
> - return rc;
> + guard(device)(dev);
guard(device)(_dax->dev); /* Only one user now */
> + return __free_dev_dax_id(dev_dax);
> }
>
> static int alloc_dev_dax_id(struct dev_dax *dev_dax)
> @@ -908,9 +890,8 @@ static ssize_t size_show(struct device *dev,
> struct dev_dax *dev_dax = to_dev_dax(dev);
> unsigned long long size;
>
> - device_lock(dev);
> + guard(device)(dev);
> size = dev_dax_size(dev_dax);
> - device_unlock(dev);
>
> return sprintf(buf, "%llu\n", size);
Might as well make this
guard(device)(dev);
return sprintf(buf, "%llu\n", dev_dax_size(to_dev_dax(dev));
> }
Re: [PATCH v4 1/3] Documentatiion/ABI: Add ABI documentation for sys-bus-dax
On Tue, 12 Dec 2023 12:08:30 -0700 Vishal Verma wrote: > Add the missing sysfs ABI documentation for the device DAX subsystem. > Various ABI attributes under this have been present since v5.1, and more > have been added over time. In preparation for adding a new attribute, > add this file with the historical details. > > Cc: Dan Williams > Signed-off-by: Vishal Verma Hi Vishal, One editorial suggestions. I don't know the interface well enough to do a good review of the content so leaving that for Dan or others. > +What:/sys/bus/dax/devices/daxX.Y/mapping[0..N]/start > +Date:October, 2020 > +KernelVersion: v5.10 > +Contact: nvd...@lists.linux.dev > +Description: > + (RO) A dax device may have multiple constituent discontiguous > + address ranges. These are represented by the different > + 'mappingX' subdirectories. The 'start' attribute indicates the > + start physical address for the given range. A common option for these files is to have a single entry with two What: lines. Here that would avoid duplication of majority of this text across the start, end and page_offset entries. Alternatively you could do an entry for the mapping[0..N] directory with the shared text then separate entries for the 3 files under there. > + > +What:/sys/bus/dax/devices/daxX.Y/mapping[0..N]/end > +Date:October, 2020 > +KernelVersion: v5.10 > +Contact: nvd...@lists.linux.dev > +Description: > + (RO) A dax device may have multiple constituent discontiguous > + address ranges. These are represented by the different > + 'mappingX' subdirectories. The 'end' attribute indicates the > + end physical address for the given range. > + > +What:/sys/bus/dax/devices/daxX.Y/mapping[0..N]/page_offset > +Date:October, 2020 > +KernelVersion: v5.10 > +Contact: nvd...@lists.linux.dev > +Description: > + (RO) A dax device may have multiple constituent discontiguous > + address ranges. These are represented by the different > + 'mappingX' subdirectories. The 'page_offset' attribute > indicates the > + offset of the current range in the dax device.
Re: [PATCH v4 2/3] dax/bus: Introduce guard(device) for device_{lock,unlock} flows
On Tue, 12 Dec 2023 12:08:31 -0700
Vishal Verma wrote:
> Introduce a guard(device) macro to lock a 'struct device', and unlock it
> automatically when going out of scope using Scope Based Resource
> Management semantics. A lot of the sysfs attribute writes in
> drivers/dax/bus.c benefit from a cleanup using these, so change these
> where applicable.
>
> Cc: Joao Martins
> Suggested-by: Dan Williams
> Signed-off-by: Vishal Verma
Hi Vishal,
I'm a big fan of this cleanup.h stuff so very happen to see this getting used
here.
There are added opportunities for cleanup that result.
Note that almost every time I see people using this stuff they don't look again
at the code post the change so miss the wider cleanup that it enables. So you
are
in good company ;)
Jonathan
> ---
> include/linux/device.h | 2 +
> drivers/dax/bus.c | 109
> +++--
> 2 files changed, 44 insertions(+), 67 deletions(-)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index d7a72a8749ea..a83efd9ae949 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -1131,6 +1131,8 @@ void set_secondary_fwnode(struct device *dev, struct
> fwnode_handle *fwnode);
> void device_set_of_node_from_dev(struct device *dev, const struct device
> *dev2);
> void device_set_node(struct device *dev, struct fwnode_handle *fwnode);
>
> +DEFINE_GUARD(device, struct device *, device_lock(_T), device_unlock(_T))
Nice. I'd expect this to be widely adopted, so maybe to make things less painful
for backporting changes that depend on it, make this a separate trivial patch
rather than having this in here.
> +
> static inline int dev_num_vf(struct device *dev)
> {
> if (dev->bus && dev->bus->num_vf)
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 1ff1ab5fa105..ce1356ac6dc2 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -296,9 +296,8 @@ static ssize_t available_size_show(struct device *dev,
> struct dax_region *dax_region = dev_get_drvdata(dev);
> unsigned long long size;
>
> - device_lock(dev);
> + guard(device)(dev);
> size = dax_region_avail_size(dax_region);
> - device_unlock(dev);
>
> return sprintf(buf, "%llu\n", size);
return sprintf(buf, @%llu\n@, dax_region_avail_size(dax_region));
and drop the local variable that adds little perhaps?
> }
> @@ -314,10 +313,9 @@ static ssize_t seed_show(struct device *dev,
> if (is_static(dax_region))
> return -EINVAL;
>
> - device_lock(dev);
> + guard(device)(dev);
> seed = dax_region->seed;
> rc = sprintf(buf, "%s\n", seed ? dev_name(seed) : "");
return sprintf();
> - device_unlock(dev);
>
> return rc;
> }
> @@ -333,10 +331,9 @@ static ssize_t create_show(struct device *dev,
> if (is_static(dax_region))
> return -EINVAL;
>
> - device_lock(dev);
> + guard(device)(dev);
> youngest = dax_region->youngest;
> rc = sprintf(buf, "%s\n", youngest ? dev_name(youngest) : "");
return sprintf();
> - device_unlock(dev);
>
> return rc;
> }
> @@ -345,7 +342,14 @@ static ssize_t create_store(struct device *dev, struct
> device_attribute *attr,
> const char *buf, size_t len)
> {
> struct dax_region *dax_region = dev_get_drvdata(dev);
> + struct dev_dax_data data = {
> + .dax_region = dax_region,
> + .size = 0,
> + .id = -1,
> + .memmap_on_memory = false,
> + };
> unsigned long long avail;
> + struct dev_dax *dev_dax;
> ssize_t rc;
> int val;
>
> @@ -358,38 +362,26 @@ static ssize_t create_store(struct device *dev, struct
> device_attribute *attr,
> if (val != 1)
> return -EINVAL;
>
> - device_lock(dev);
> + guard(device)(dev);
> avail = dax_region_avail_size(dax_region);
> if (avail == 0)
> - rc = -ENOSPC;
> - else {
> - struct dev_dax_data data = {
> - .dax_region = dax_region,
> - .size = 0,
> - .id = -1,
> - .memmap_on_memory = false,
> - };
> - struct dev_dax *dev_dax = devm_create_dev_dax();
> + return -ENOSPC;
>
> - if (IS_ERR(dev_dax))
> - rc = PTR_ERR(dev_dax);
> - else {
> - /*
> - * In support of crafting multiple new devices
> - * simultaneously multiple seeds can be created,
> - * but only the first one that has not been
> - * successfully bound is tracked as the region
> - * seed.
> - */
> - if (!dax_region->seed)
> - dax_region->seed = _dax->dev;
> - dax_region->youngest = _dax->dev;
> -
Re: [PATCH] dt-bindings: correct white-spaces in examples
On Fri, 24 Nov 2023 10:21:21 +0100
Krzysztof Kozlowski wrote:
> Use only one and exactly one space around '=' in DTS example.
>
> Signed-off-by: Krzysztof Kozlowski
>
Acked-by: Jonathan Cameron #for-iio
> ---
>
> Merging idea: Rob's DT.
> Should apply cleanly on Rob's for-next.
> ---
> .../devicetree/bindings/auxdisplay/hit,hd44780.yaml | 2 +-
> .../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml | 2 +-
> Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 6 +++---
> .../devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml | 2 +-
> .../devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml | 2 +-
> .../interrupt-controller/st,stih407-irq-syscfg.yaml | 4 ++--
> Documentation/devicetree/bindings/mmc/arm,pl18x.yaml | 2 +-
> Documentation/devicetree/bindings/net/sff,sfp.yaml| 2 +-
> .../devicetree/bindings/pci/toshiba,visconti-pcie.yaml| 2 +-
> .../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 6 +++---
> .../devicetree/bindings/power/supply/richtek,rt9455.yaml | 8
> .../devicetree/bindings/regulator/mps,mp5416.yaml | 4 ++--
> .../devicetree/bindings/regulator/mps,mpq7920.yaml| 4 ++--
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8
> 14 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
> b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
> index fde07e4b119d..406a922a714e 100644
> --- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
> +++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
> @@ -113,7 +113,7 @@ examples:
> hd44780 {
> compatible = "hit,hd44780";
> display-height-chars = <2>;
> -display-width-chars = <16>;
> +display-width-chars = <16>;
> data-gpios = < 4 0>,
> < 5 0>,
> < 6 0>,
> diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> index 624984d51c10..7f8d98226437 100644
> --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> @@ -125,7 +125,7 @@ examples:
> clk25m: clock-oscillator-25m {
>compatible = "fixed-clock";
>#clock-cells = <0>;
> - clock-frequency = <2500>;
> + clock-frequency = <2500>;
>clock-output-names = "clk25m";
> };
> ...
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> index 5fcc8dd012f1..be2616ff9af6 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> @@ -80,9 +80,9 @@ examples:
> compatible = "adi,ad7780";
> reg = <0>;
>
> -avdd-supply = <_supply>;
> -powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> -adi,gain-gpios = < 5 GPIO_ACTIVE_LOW>;
> +avdd-supply = <_supply>;
> +powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +adi,gain-gpios = < 5 GPIO_ACTIVE_LOW>;
> adi,filter-gpios = < 15 GPIO_ACTIVE_LOW>;
> };
> };
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
> index 73def67fbe01..b6a233cd5f6b 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml
> @@ -58,7 +58,7 @@ examples:
> reg = <0x3600>;
> interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
> qcom,external-resistor-micro-ohms = <1>;
> -#io-channel-cells = <1>;
> +#io-channel-cells = <1>;
> };
> };
> ...
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
> index b3a626389870..64abe9a4cd9e 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-rradc.yaml
> @@ -46,6 +46,6 @@ examples:
> pmic_rradc: adc@4500 {
> compatible = "qcom,pmi8998-rradc";
> reg = <0x4500>;
> -#io-channe
Re: [PATCH 1/4] iio: adc: Add PM7325 PMIC7 ADC bindings
On Fri, 13 Oct 2023 10:09:53 +0200 Luca Weiss wrote: > Add the defines for the ADC channels found on the PM7325. The list is > taken from downstream msm-5.4 and adjusted for mainline. > > Signed-off-by: Luca Weiss I assume this will go with the dts changes that use it. Acked-by: Jonathan Cameron > --- > include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h | 69 > + > 1 file changed, 69 insertions(+) > > diff --git a/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > b/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > new file mode 100644 > index ..96908014e09e > --- /dev/null > +++ b/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > @@ -0,0 +1,69 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (c) 2020 The Linux Foundation. All rights reserved. > + */ > + > +#ifndef _DT_BINDINGS_QCOM_SPMI_VADC_PM7325_H > +#define _DT_BINDINGS_QCOM_SPMI_VADC_PM7325_H > + > +#ifndef PM7325_SID > +#define PM7325_SID 1 > +#endif > + > +#include > + > +/* ADC channels for PM7325_ADC for PMIC7 */ > +#define PM7325_ADC7_REF_GND (PM7325_SID << 8 | ADC7_REF_GND) > +#define PM7325_ADC7_1P25VREF (PM7325_SID << 8 | > ADC7_1P25VREF) > +#define PM7325_ADC7_VREF_VADC(PM7325_SID << 8 | > ADC7_VREF_VADC) > +#define PM7325_ADC7_DIE_TEMP (PM7325_SID << 8 | > ADC7_DIE_TEMP) > + > +#define PM7325_ADC7_AMUX_THM1(PM7325_SID << 8 | > ADC7_AMUX_THM1) > +#define PM7325_ADC7_AMUX_THM2(PM7325_SID << 8 | > ADC7_AMUX_THM2) > +#define PM7325_ADC7_AMUX_THM3(PM7325_SID << 8 | > ADC7_AMUX_THM3) > +#define PM7325_ADC7_AMUX_THM4(PM7325_SID << 8 | > ADC7_AMUX_THM4) > +#define PM7325_ADC7_AMUX_THM5(PM7325_SID << 8 | > ADC7_AMUX_THM5) > +#define PM7325_ADC7_GPIO1(PM7325_SID << 8 | ADC7_GPIO1) > +#define PM7325_ADC7_GPIO2(PM7325_SID << 8 | ADC7_GPIO2) > +#define PM7325_ADC7_GPIO3(PM7325_SID << 8 | ADC7_GPIO3) > +#define PM7325_ADC7_GPIO4(PM7325_SID << 8 | ADC7_GPIO4) > + > +/* 30k pull-up1 */ > +#define PM7325_ADC7_AMUX_THM1_30K_PU (PM7325_SID << 8 | > ADC7_AMUX_THM1_30K_PU) > +#define PM7325_ADC7_AMUX_THM2_30K_PU (PM7325_SID << 8 | > ADC7_AMUX_THM2_30K_PU) > +#define PM7325_ADC7_AMUX_THM3_30K_PU (PM7325_SID << 8 | > ADC7_AMUX_THM3_30K_PU) > +#define PM7325_ADC7_AMUX_THM4_30K_PU (PM7325_SID << 8 | > ADC7_AMUX_THM4_30K_PU) > +#define PM7325_ADC7_AMUX_THM5_30K_PU (PM7325_SID << 8 | > ADC7_AMUX_THM5_30K_PU) > +#define PM7325_ADC7_GPIO1_30K_PU (PM7325_SID << 8 | > ADC7_GPIO1_30K_PU) > +#define PM7325_ADC7_GPIO2_30K_PU (PM7325_SID << 8 | > ADC7_GPIO2_30K_PU) > +#define PM7325_ADC7_GPIO3_30K_PU (PM7325_SID << 8 | > ADC7_GPIO3_30K_PU) > +#define PM7325_ADC7_GPIO4_30K_PU (PM7325_SID << 8 | > ADC7_GPIO4_30K_PU) > + > +/* 100k pull-up2 */ > +#define PM7325_ADC7_AMUX_THM1_100K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM1_100K_PU) > +#define PM7325_ADC7_AMUX_THM2_100K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM2_100K_PU) > +#define PM7325_ADC7_AMUX_THM3_100K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM3_100K_PU) > +#define PM7325_ADC7_AMUX_THM4_100K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM4_100K_PU) > +#define PM7325_ADC7_AMUX_THM5_100K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM5_100K_PU) > +#define PM7325_ADC7_GPIO1_100K_PU(PM7325_SID << 8 | > ADC7_GPIO1_100K_PU) > +#define PM7325_ADC7_GPIO2_100K_PU(PM7325_SID << 8 | > ADC7_GPIO2_100K_PU) > +#define PM7325_ADC7_GPIO3_100K_PU(PM7325_SID << 8 | > ADC7_GPIO3_100K_PU) > +#define PM7325_ADC7_GPIO4_100K_PU(PM7325_SID << 8 | > ADC7_GPIO4_100K_PU) > + > +/* 400k pull-up3 */ > +#define PM7325_ADC7_AMUX_THM1_400K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM1_400K_PU) > +#define PM7325_ADC7_AMUX_THM2_400K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM2_400K_PU) > +#define PM7325_ADC7_AMUX_THM3_400K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM3_400K_PU) > +#define PM7325_ADC7_AMUX_THM4_400K_PU(PM7325_SID << 8 | > ADC7_AMUX_THM4_400K_PU) > +#define PM7325_ADC7_AMUX_THM5_400K_PU(P
Re: [PATCH RESEND 2/4] acpi, hmat: refactor hmat_register_target_initiators()
On Fri, 21 Jul 2023 09:29:30 +0800
Huang Ying wrote:
> Previously, in hmat_register_target_initiators(), the performance
> attributes are calculated and the corresponding sysfs links and files
> are created too. Which is called during memory onlining.
>
> But now, to calculate the abstract distance of a memory target before
> memory onlining, we need to calculate the performance attributes for
> a memory target without creating sysfs links and files.
>
> To do that, hmat_register_target_initiators() is refactored to make it
> possible to calculate performance attributes separately.
>
> Signed-off-by: "Huang, Ying"
> Cc: Aneesh Kumar K.V
> Cc: Wei Xu
> Cc: Alistair Popple
> Cc: Dan Williams
> Cc: Dave Hansen
> Cc: Davidlohr Bueso
> Cc: Johannes Weiner
> Cc: Jonathan Cameron
> Cc: Michal Hocko
> Cc: Yang Shi
> Cc: Rafael J Wysocki
Unfortunately I don't think I still have the tables I used to test the
generic initiator and won't get time to generate them all again in
next few weeks. So just a superficial review for now.
I 'think' the cleanup looks good but the original code was rather fiddly
so I'm not 100% sure nothing is missed.
One comment inline on the fact the list is now sorted twice.
> ---
> drivers/acpi/numa/hmat.c | 81 +++-
> 1 file changed, 30 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
> index bba268ecd802..2dee0098f1a9 100644
> --- a/drivers/acpi/numa/hmat.c
> +++ b/drivers/acpi/numa/hmat.c
> @@ -582,28 +582,25 @@ static int initiators_to_nodemask(unsigned long
> *p_nodes)
> return 0;
> }
>
> -static void hmat_register_target_initiators(struct memory_target *target)
> +static void hmat_update_target_attrs(struct memory_target *target,
> + unsigned long *p_nodes, int access)
> {
> - static DECLARE_BITMAP(p_nodes, MAX_NUMNODES);
> struct memory_initiator *initiator;
> - unsigned int mem_nid, cpu_nid;
> + unsigned int cpu_nid;
> struct memory_locality *loc = NULL;
> u32 best = 0;
> - bool access0done = false;
> int i;
>
> - mem_nid = pxm_to_node(target->memory_pxm);
> + bitmap_zero(p_nodes, MAX_NUMNODES);
> /*
> - * If the Address Range Structure provides a local processor pxm, link
> + * If the Address Range Structure provides a local processor pxm, set
>* only that one. Otherwise, find the best performance attributes and
> - * register all initiators that match.
> + * collect all initiators that match.
>*/
> if (target->processor_pxm != PXM_INVAL) {
> cpu_nid = pxm_to_node(target->processor_pxm);
> - register_memory_node_under_compute_node(mem_nid, cpu_nid, 0);
> - access0done = true;
> - if (node_state(cpu_nid, N_CPU)) {
> - register_memory_node_under_compute_node(mem_nid,
> cpu_nid, 1);
> + if (access == 0 || node_state(cpu_nid, N_CPU)) {
> + set_bit(target->processor_pxm, p_nodes);
> return;
> }
> }
> @@ -617,47 +614,10 @@ static void hmat_register_target_initiators(struct
> memory_target *target)
>* We'll also use the sorting to prime the candidate nodes with known
>* initiators.
>*/
> - bitmap_zero(p_nodes, MAX_NUMNODES);
> list_sort(NULL, , initiator_cmp);
> if (initiators_to_nodemask(p_nodes) < 0)
> return;
One result of this refactor is that a few things run twice, that previously
only ran once
like this list_sort()
Not necessarily a problem though as probably fairly cheap.
>
> - if (!access0done) {
> - for (i = WRITE_LATENCY; i <= READ_BANDWIDTH; i++) {
> - loc = localities_types[i];
> - if (!loc)
> - continue;
> -
> - best = 0;
> - list_for_each_entry(initiator, , node) {
> - u32 value;
> -
> - if (!test_bit(initiator->processor_pxm,
> p_nodes))
> - continue;
> -
> - value = hmat_initiator_perf(target, initiator,
> - loc->hmat_loc);
> - if (hmat_update_best(loc->hmat_loc->data_type,
> value, ))
> - bitmap_clear(p_nodes, 0,
> initiator->processor_pxm);
> - if (value != best)
> -
Re: [PATCH v3 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory
On Tue, 01 Aug 2023 23:55:38 -0600 Vishal Verma wrote: > Large amounts of memory managed by the kmem driver may come in via CXL, > and it is often desirable to have the memmap for this memory on the new > memory itself. > > Enroll kmem-managed memory for memmap_on_memory semantics as a default. > Add a sysfs override under the dax device to opt out of this behavior. > > Cc: Andrew Morton > Cc: David Hildenbrand > Cc: Michal Hocko > Cc: Oscar Salvador > Cc: Dan Williams > Cc: Dave Jiang > Cc: Dave Hansen > Cc: Huang Ying > Signed-off-by: Vishal Verma Hi Vishal, In general looks fine to me. Just a question for potential discussion if didn't miss it in earlier versions. FWIW Reviewed-by: Jonathan Cameron Also, any docs need updating? Doesn't seem like the DAX ABI docs are present in Documentation/ABI so not sure where it should be updated. Jonathan > > @@ -1400,6 +1435,13 @@ struct dev_dax *devm_create_dev_dax(struct > dev_dax_data *data) > dev_dax->align = dax_region->align; > ida_init(_dax->ida); > > + /* > + * If supported by memory_hotplug, allow memmap_on_memory behavior by > + * default. This can be overridden via sysfs before handing the memory > + * over to kmem if desired. > + */ > + dev_dax->memmap_on_memory = true; If there are existing users, then this is a fairly significant change of defaults. Maybe it should be false and opt in rather than out? > + > inode = dax_inode(dax_dev); > dev->devt = inode->i_rdev; > dev->bus = _bus_type;
Re: [PATCH v3 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks
On Tue, 01 Aug 2023 23:55:37 -0600
Vishal Verma wrote:
> The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
> 'memblock_size' chunks of memory being added. Adding a larger span of
> memory precludes memmap_on_memory semantics.
>
> For users of hotplug such as kmem, large amounts of memory might get
> added from the CXL subsystem. In some cases, this amount may exceed the
> available 'main memory' to store the memmap for the memory being added.
> In this case, it is useful to have a way to place the memmap on the
> memory being added, even if it means splitting the addition into
> memblock-sized chunks.
>
> Change add_memory_resource() to loop over memblock-sized chunks of
> memory if caller requested memmap_on_memory, and if other conditions for
> it are met. Teach try_remove_memory() to also expect that a memory
> range being removed might have been split up into memblock sized chunks,
> and to loop through those as needed.
>
> Cc: Andrew Morton
> Cc: David Hildenbrand
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Dan Williams
> Cc: Dave Jiang
> Cc: Dave Hansen
> Cc: Huang Ying
> Suggested-by: David Hildenbrand
> Signed-off-by: Vishal Verma
A couple of trivial comments inline.
> ---
> mm/memory_hotplug.c | 150
>
> 1 file changed, 93 insertions(+), 57 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index d282664f558e..cae03c8d4bbf 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1383,6 +1383,44 @@ static bool mhp_supports_memmap_on_memory(unsigned
> long size)
> return arch_supports_memmap_on_memory(vmemmap_size);
> }
>
> +static int add_memory_create_devices(int nid, struct memory_group *group,
> + u64 start, u64 size, mhp_t mhp_flags)
> +{
> + struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) };
> + struct vmem_altmap mhp_altmap = {
> + .base_pfn = PHYS_PFN(start),
> + .end_pfn = PHYS_PFN(start + size - 1),
> + };
> + int ret;
> +
> + if ((mhp_flags & MHP_MEMMAP_ON_MEMORY)) {
> + mhp_altmap.free = memory_block_memmap_on_memory_pages();
> + params.altmap = kmalloc(sizeof(struct vmem_altmap), GFP_KERNEL);
> + if (!params.altmap)
> + return -ENOMEM;
> +
> + memcpy(params.altmap, _altmap, sizeof(mhp_altmap));
> + }
> +
> + /* call arch's memory hotadd */
> + ret = arch_add_memory(nid, start, size, );
> + if (ret < 0)
> + goto error;
> +
> + /* create memory block devices after memory was added */
> + ret = create_memory_block_devices(start, size, params.altmap, group);
> + if (ret) {
> + arch_remove_memory(start, size, NULL);
Maybe push this down to a second label?
> + goto error;
> + }
> +
> + return 0;
> +
> +error:
> + kfree(params.altmap);
> + return ret;
> +}
> +
> /*
> * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
> * and online/offline operations (triggered e.g. by sysfs).
> @@ -1391,14 +1429,10 @@ static bool mhp_supports_memmap_on_memory(unsigned
> long size)
> */
> int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
> {
> - struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) };
> + unsigned long memblock_size = memory_block_size_bytes();
> enum memblock_flags memblock_flags = MEMBLOCK_NONE;
> - struct vmem_altmap mhp_altmap = {
> - .base_pfn = PHYS_PFN(res->start),
> - .end_pfn = PHYS_PFN(res->end),
> - };
> struct memory_group *group = NULL;
> - u64 start, size;
> + u64 start, size, cur_start;
> bool new_node = false;
> int ret;
>
> @@ -1439,28 +1473,21 @@ int __ref add_memory_resource(int nid, struct
> resource *res, mhp_t mhp_flags)
> /*
>* Self hosted memmap array
>*/
> - if (mhp_flags & MHP_MEMMAP_ON_MEMORY) {
> - if (mhp_supports_memmap_on_memory(size)) {
> - mhp_altmap.free = memory_block_memmap_on_memory_pages();
> - params.altmap = kmalloc(sizeof(struct vmem_altmap),
> GFP_KERNEL);
> - if (!params.altmap)
> + if ((mhp_flags & MHP_MEMMAP_ON_MEMORY) &&
> + mhp_supports_memmap_on_memory(memblock_size)) {
> + for (cur_start = start; cur_start < start + size;
> + cur_start += memblock_size) {
> + ret = add_memory_create_devices(nid, group, cur_start,
> + memblock_size,
> + mhp_flags);
> + if (ret)
> goto error;
> -
> - memcpy(params.altmap, _altmap, sizeof(mhp_altmap));
> }
> - /* fallback to not using altmap
Re: [PATCH 1/3] mm/memory_hotplug: Allow an override for the memmap_on_memory param
On Fri, 16 Jun 2023 09:46:59 +0200 David Hildenbrand wrote: > On 16.06.23 00:00, Vishal Verma wrote: > > For memory hotplug to consider MHP_MEMMAP_ON_MEMORY behavior, the > > 'memmap_on_memory' module parameter was a hard requirement. > > > > In preparation for the dax/kmem driver to use memmap_on_memory > > semantics, arrange for the module parameter check to be bypassed via the > > appropriate mhp_flag. > > > > Recall that the kmem driver could contribute huge amounts of hotplugged > > memory originating from special purposes devices such as CXL memory > > expanders. In some cases memmap_on_memory may be the /only/ way this new > > memory can be hotplugged. Hence it makes sense for kmem to have a way to > > force memmap_on_memory without depending on a module param, if all the > > other conditions for it are met. > > Just let the admin configure it. After all, an admin is involved in > configuring the dax/kmem device to begin with. If add_memory() fails you > could give a useful hint to the admin. > Agreed. If it were just the default then fine, but making it the only option limits admin choices. Jonathan
[PATCH 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Mon, 19 Apr 2021 20:45:08 +0100 Jonathan Cameron wrote: > On Mon, 19 Apr 2021 16:34:35 +0300 > Tomas Melin wrote: > > > Hi, > > > > On 4/18/21 1:03 PM, Jonathan Cameron wrote: > > > On Fri, 16 Apr 2021 15:21:14 +0300 > > > Tomas Melin wrote: > > > > > >> Updated email-address for Alexandru. > > >> > > >> > > >> On 4/16/21 3:17 PM, Tomas Melin wrote: > > >>> On 4/15/21 11:41 AM, Tomas Melin wrote: > > >>> > > >>>> While working on updates I did notice something new which I cannot > > >>>> > > >>>> reproduce on older (5.10.17 kernel) version. If compiling this as a > > >>>> module, getting error while > > >>>> > > >>>> unloading module: > > >>>> > > >>>> [ 40.200084] Unable to handle kernel NULL pointer dereference at > > >>>> virtual address 0104 > > >>>> ... > > >>>> > > >>>> [ 40.510054] Backtrace: > > >>>> [ 40.512502] [] (iio_device_ioctl_handler_unregister) > > >>>> from [] (iio_buffers_free_sysfs_and_mask+0x2c/0x6c) > > >>>> [ 40.523735] [] (iio_buffers_free_sysfs_and_mask) from > > >>>> [] (iio_device_unregister+0xa8/0xac) > > >>>> [ 40.533746] r5:c1811228 r4:c1811000 > > >>>> [ 40.537318] [] (iio_device_unregister) from [] > > >>>> (devm_iio_device_unreg+0x1c/0x20) > > >>>> [ 40.546461] r5:c2415000 r4:c25bab80 > > >>>> [ 40.550025] [] (devm_iio_device_unreg) from [] > > >>>> (release_nodes+0x1c0/0x1f0) > > >>>> [ 40.558654] [] (release_nodes) from [] > > >>>> (devres_release_all+0x40/0x60) > > >>>> [ 40.566847] r10:0081 r9:c235 r8:c0100264 r7:0081 > > >>>> r6:bf00c010 r5:c19be000 > > >>>> [ 40.574669] r4:c1a91c00 > > >>>> [ 40.577194] [] (devres_release_all) from [] > > >>>> (device_release_driver_internal+0x120/0x1cc) > > >>>> [ 40.587031] r5:c19be000 r4:c1a91c00 > > >>>> [ 40.590596] [] (device_release_driver_internal) from > > >>>> [] (driver_detach+0x54/0x90) > > >>>> [ 40.599828] r7:0081 r6: r5:bf00c010 r4:c1a91c00 > > >>>> [ 40.605482] [] (driver_detach) from [] > > >>>> (bus_remove_driver+0x5c/0xb0) > > >>>> [ 40.613583] r5:0800 r4:bf00c010 > > >>>> [ 40.617148] [] (bus_remove_driver) from [] > > >>>> (driver_unregister+0x38/0x5c) > > >>>> [ 40.625596] r5:0800 r4:bf00c010 > > >>>> [ 40.629161] [] (driver_unregister) from [] > > >>>> (sca3300_driver_exit+0x14/0x8b4 [sca3300]) > > >>>> [ 40.638747] r5:0800 r4:bf00c080 > > >>>> [ 40.642311] [] (sca3300_driver_exit [sca3300]) from > > >>>> [] (sys_delete_module+0x16c/0x238) > > >>>> [ 40.651990] [] (sys_delete_module) from [] > > >>>> (__sys_trace_return+0x0/0x1c) > > >>>> [ 40.660435] Exception stack(0xc2351fa8 to 0xc2351ff0) > > >>>> [ 40.665484] 1fa0: 0050e5a8 0050e5e4 > > >>>> 0800 081d4b00 bec18af4 > > >>>> [ 40.673661] 1fc0: 0050e5a8 bec18b50 0081 bec18e51 > > >>>> 0050e190 0001 bec18d3c > > >>>> [ 40.681834] 1fe0: 0050cf70 bec18afc 004f1ec8 b6ecb27c > > >>>> [ 40.686887] r6:bec18b50 r5: r4:0050e5a8 > > >>>> [ 40.691507] Code: e8bd4000 e1c020d0 e3a0cc01 e3001122 (e5823004) > > >>>> [ 40.707675] ---[ end trace 189882b050077333 ]--- > > >>>> > > >>>> This happens when building against linux-next > > >>>> 5.12.0-rc6-next-20210409. I'm failing to see what is wrong. Any ideas? > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Tomas > > >>> > > >>> Tested further that for this driver, loading and unloading as module > > >>> works fine until commit: > > >>> > > >>> commit f73f7f4da581875f9b1f2fb8ebd1ab15ed634488 > > >>> Author: Alexandru Ardelean > > >>> Date: Mon Feb 15 12:40:39 2021 +0200 > > >>> > > >&g
Re: [PATCH 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Mon, 19 Apr 2021 16:34:35 +0300 Tomas Melin wrote: > Hi, > > On 4/18/21 1:03 PM, Jonathan Cameron wrote: > > On Fri, 16 Apr 2021 15:21:14 +0300 > > Tomas Melin wrote: > > > >> Updated email-address for Alexandru. > >> > >> > >> On 4/16/21 3:17 PM, Tomas Melin wrote: > >>> On 4/15/21 11:41 AM, Tomas Melin wrote: > >>> > >>>> While working on updates I did notice something new which I cannot > >>>> > >>>> reproduce on older (5.10.17 kernel) version. If compiling this as a > >>>> module, getting error while > >>>> > >>>> unloading module: > >>>> > >>>> [ 40.200084] Unable to handle kernel NULL pointer dereference at > >>>> virtual address 0104 > >>>> ... > >>>> > >>>> [ 40.510054] Backtrace: > >>>> [ 40.512502] [] (iio_device_ioctl_handler_unregister) > >>>> from [] (iio_buffers_free_sysfs_and_mask+0x2c/0x6c) > >>>> [ 40.523735] [] (iio_buffers_free_sysfs_and_mask) from > >>>> [] (iio_device_unregister+0xa8/0xac) > >>>> [ 40.533746] r5:c1811228 r4:c1811000 > >>>> [ 40.537318] [] (iio_device_unregister) from [] > >>>> (devm_iio_device_unreg+0x1c/0x20) > >>>> [ 40.546461] r5:c2415000 r4:c25bab80 > >>>> [ 40.550025] [] (devm_iio_device_unreg) from [] > >>>> (release_nodes+0x1c0/0x1f0) > >>>> [ 40.558654] [] (release_nodes) from [] > >>>> (devres_release_all+0x40/0x60) > >>>> [ 40.566847] r10:0081 r9:c235 r8:c0100264 r7:0081 > >>>> r6:bf00c010 r5:c19be000 > >>>> [ 40.574669] r4:c1a91c00 > >>>> [ 40.577194] [] (devres_release_all) from [] > >>>> (device_release_driver_internal+0x120/0x1cc) > >>>> [ 40.587031] r5:c19be000 r4:c1a91c00 > >>>> [ 40.590596] [] (device_release_driver_internal) from > >>>> [] (driver_detach+0x54/0x90) > >>>> [ 40.599828] r7:0081 r6: r5:bf00c010 r4:c1a91c00 > >>>> [ 40.605482] [] (driver_detach) from [] > >>>> (bus_remove_driver+0x5c/0xb0) > >>>> [ 40.613583] r5:0800 r4:bf00c010 > >>>> [ 40.617148] [] (bus_remove_driver) from [] > >>>> (driver_unregister+0x38/0x5c) > >>>> [ 40.625596] r5:0800 r4:bf00c010 > >>>> [ 40.629161] [] (driver_unregister) from [] > >>>> (sca3300_driver_exit+0x14/0x8b4 [sca3300]) > >>>> [ 40.638747] r5:0800 r4:bf00c080 > >>>> [ 40.642311] [] (sca3300_driver_exit [sca3300]) from > >>>> [] (sys_delete_module+0x16c/0x238) > >>>> [ 40.651990] [] (sys_delete_module) from [] > >>>> (__sys_trace_return+0x0/0x1c) > >>>> [ 40.660435] Exception stack(0xc2351fa8 to 0xc2351ff0) > >>>> [ 40.665484] 1fa0: 0050e5a8 0050e5e4 > >>>> 0800 081d4b00 bec18af4 > >>>> [ 40.673661] 1fc0: 0050e5a8 bec18b50 0081 bec18e51 > >>>> 0050e190 0001 bec18d3c > >>>> [ 40.681834] 1fe0: 0050cf70 bec18afc 004f1ec8 b6ecb27c > >>>> [ 40.686887] r6:bec18b50 r5: r4:0050e5a8 > >>>> [ 40.691507] Code: e8bd4000 e1c020d0 e3a0cc01 e3001122 (e5823004) > >>>> [ 40.707675] ---[ end trace 189882b050077333 ]--- > >>>> > >>>> This happens when building against linux-next > >>>> 5.12.0-rc6-next-20210409. I'm failing to see what is wrong. Any ideas? > >>>> > >>>> Thanks, > >>>> > >>>> Tomas > >>> > >>> Tested further that for this driver, loading and unloading as module > >>> works fine until commit: > >>> > >>> commit f73f7f4da581875f9b1f2fb8ebd1ab15ed634488 > >>> Author: Alexandru Ardelean > >>> Date: Mon Feb 15 12:40:39 2021 +0200 > >>> > >>> iio: buffer: add ioctl() to support opening extra buffers for IIO > >>> device > >>> > >>> > >>> Any thoughts what causes this issue? > > Is this still happening after fixing the ordering in probe / remove? > > (devm_iio_triggered_buffer_setup() being easiest way) > > > > As driver currently stands it's calling iio_triggered_buffer_cleanup > > before the managed cleanup of the iio_device_register() cal
Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Sun, 18 Apr 2021 16:59:02 +0300 Andy Shevchenko wrote: > On Sun, Apr 18, 2021 at 4:49 PM Andy Shevchenko > wrote: > > > > On Sun, Apr 18, 2021 at 2:07 PM Jonathan Cameron wrote: > > > > Thanks for review, my answers below. > > > > > On Wed, 14 Apr 2021 22:54:53 +0300 > > > Andy Shevchenko wrote: > > > > > > > We can utilize separate drivers for accelerometer and magnetometer, > > > > so here is the glue driver to enable LSM9DS0 IMU support. > > > > > > > > The idea was suggested by Crestez Dan Leonard in [1]. The proposed > > > > change > > > > was sent as RFC due to race condition concerns, which are indeed > > > > possible. > > > > > > If you are going to mention races, good to give some flavour in here! > > > > I meant that the initial idea is racy due to different devices > > communicating to the same i2c address. > > So, any sequence of transfers are not serialized and you may end up with > > > > drv1 -> i2c > > drv2 -> i2c > > drv1 <- i2c # garbage > > > > > This driver makes me very nervous indeed. > > > > Why?! This one is race free as far as I can see. Or maybe I interpret > > this wrongly and you are talking about initial RFC? > > > > > I haven't 'found' any places > > > where the fact we'll write the same registers from each of the drivers > > > causes problems (e.g. int pin setup etc) but perhaps I'm missing > > > something. > > > > > > Shall we say that makes me rather keener to get eyes (and thought) on this > > > patch than normal :) > > > > How should I amend the commit message to state: > > 1. First idea (RFC by the link) *is* racy AFAIU > > 2. This one *is not* racy. Great. I read it as meaning they were both potentially racey! This is less worrying. > > I re-read this and now understand better what you meant. > So, it may be that the initial proposal may work without any > amendment, but since I haven't investigated much, I should rather use > the phrase "potentially racy". In my variant it's using one regmap for > both drivers (not two), which makes the register state consistent. Am > I wrong? I think this approach is fine. I'd be more worried about the two 'sub' drivers not necessarily being happy that someone else touches state they care about. There are places where I think we write the same value to the same register twice during setup with this model, but that shouldn't matter. I'm not 100% sure that there aren't other cases though I think there aren't. So what you have is probably fine, but more eyes would make me happier ;) Lots of people care about this particular driver so hopefully we'll get them. > Do we have some places where we may write to the same register concurrently? > Only ones I can find are the setup ones where it writes the same value twice I think. So *crosses fingers* :) Given timing (missed merge window) we have masses of time to let this sit on list a while and see if anyone can spot issues neither of us have found. Jonathan
Re: [PATCH v2 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Fri, 16 Apr 2021 16:45:46 +0300
Tomas Melin wrote:
> Add initial support for Murata SCA3300 3-axis industrial
> accelerometer with digital SPI interface. This device also
> provides a temperature measurement.
>
> Device product page including datasheet can be found at:
> https://www.murata.com/en-global/products/sensor/accel/sca3300
>
> Signed-off-by: Tomas Melin
A few things inline. Mostly looks pretty good
Jonathan
> ---
> drivers/iio/accel/Kconfig | 13 +
> drivers/iio/accel/Makefile | 1 +
> drivers/iio/accel/sca3300.c | 468
> 3 files changed, 482 insertions(+)
> create mode 100644 drivers/iio/accel/sca3300.c
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index cceda3cecbcf..0dbf7b648e8a 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -450,6 +450,19 @@ config SCA3000
> To compile this driver as a module, say M here: the module will be
> called sca3000.
>
> +config SCA3300
> + tristate "Murata SCA3300 3-Axis Accelerometer Driver"
> + depends on SPI
> + select CRC8
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say yes here to build support for Murata SCA3300 3-Axis
> + accelerometer.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called sca3300.
> +
> config STK8312
> tristate "Sensortek STK8312 3-Axis Accelerometer Driver"
> depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 32cd1342a31a..4b56527a2b97 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_MXC4005) += mxc4005.o
> obj-$(CONFIG_MXC6255)+= mxc6255.o
>
> obj-$(CONFIG_SCA3000)+= sca3000.o
> +obj-$(CONFIG_SCA3300)+= sca3300.o
>
> obj-$(CONFIG_STK8312)+= stk8312.o
> obj-$(CONFIG_STK8BA50) += stk8ba50.o
> diff --git a/drivers/iio/accel/sca3300.c b/drivers/iio/accel/sca3300.c
> new file mode 100644
> index ..79c3c60f9fab
> --- /dev/null
> +++ b/drivers/iio/accel/sca3300.c
> @@ -0,0 +1,468 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2021 Vaisala Oyj. All rights reserved.
> + */
> +#include
Slight preference for 'specific' includes such asm after the generic
linux ones.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SCA3300_ALIAS "sca3300"
> +
> +#define SCA3300_REG_STATUS 0x6
> +#define SCA3300_REG_MODE 0xd
> +#define SCA3300_REG_WHOAMI 0x10
> +#define SCA3300_VALUE_SW_RESET 0x20
> +#define SCA3300_CRC8_POLYNOMIAL 0x1d
> +#define SCA3300_DEVICE_ID 0x51
> +#define SCA3300_RS_ERROR 0x3
> +#define SCA3300_SELBANK 0x1f
> +#define SCA3300_STATUS_MASK 0x1ff
> +
> +enum sca3300_scan_indexes {
> + SCA3300_ACC_X = 0,
> + SCA3300_ACC_Y,
> + SCA3300_ACC_Z,
> + SCA3300_TEMP,
> + SCA3300_TIMESTAMP,
> +};
> +
> +#define SCA3300_ACCEL_CHANNEL(index, reg, axis) {\
> + .type = IIO_ACCEL, \
> + .address = reg, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = \
> + BIT(IIO_CHAN_INFO_SCALE) | \
> + BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY), \
> + .info_mask_shared_by_type_available = \
> + BIT(IIO_CHAN_INFO_SCALE) | \
> + BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY), \
> + .scan_index = index,\
> + .scan_type = { \
> + .sign = 's',\
> + .realbits = 16, \
> + .storagebits = 16, \
> + .shift = 0, \
> + .endianness = IIO_CPU, \
> + }, \
> + }
Alignment done something odd here and above. Editors get confused by
macros so you might need to tweak this carefully!
> +
> +static const struct iio_chan_spec sca3300_channels[] = {
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_X, 0x1, X),
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_Y, 0x2, Y),
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_Z, 0x3, Z),
> + {
> + .type = IIO_TEMP,
> + .address
Re: [PATCH v2 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Sat, 17 Apr 2021 15:39:12 +0300 Andy Shevchenko wrote: > On Fri, Apr 16, 2021 at 5:21 PM Tomas Melin wrote: > > > > Add initial support for Murata SCA3300 3-axis industrial > > accelerometer with digital SPI interface. This device also > > provides a temperature measurement. > > > > Device product page including datasheet can be found at: > > https://www.murata.com/en-global/products/sensor/accel/sca3300 > > Can you create a tag out of it, i.e. > > Datasheet: > > ? > > > Signed-off-by: Tomas Melin > > ... > > > obj-$(CONFIG_SCA3000) += sca3000.o > > +obj-$(CONFIG_SCA3300) += sca3300.o > > How much difference between them? Enormous :) The sca3000 series were much more exciting parts with fifos and other fun a long time before anyone else had them. That part drove a lot of the weirder corners of IIO in the early days and had features that didn't show up anywhere else for quite a few years. The sca3100 onwards were much simpler (from software point of view) - I guess Murata have a different focus than VTI did. Jonathan
Re: [PATCH 1/2] HID: hid-sensor-hub: Return error for hid_set_field() failure
On Thu, 15 Apr 2021 11:52:31 -0700
Srinivas Pandruvada wrote:
> In the function sensor_hub_set_feature(), return error when hid_set_field()
> fails.
>
> Signed-off-by: Srinivas Pandruvada
Series applied to the to greg branch of iio.git. Note these won't make the
coming merge window, so will turn up in next sometime after rc1.
thanks,
Jonathan
> ---
> drivers/hid/hid-sensor-hub.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index 3dd7d3246737..f9983145d4e7 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -210,16 +210,21 @@ int sensor_hub_set_feature(struct hid_sensor_hub_device
> *hsdev, u32 report_id,
> buffer_size = buffer_size / sizeof(__s32);
> if (buffer_size) {
> for (i = 0; i < buffer_size; ++i) {
> - hid_set_field(report->field[field_index], i,
> - (__force __s32)cpu_to_le32(*buf32));
> + ret = hid_set_field(report->field[field_index], i,
> + (__force __s32)cpu_to_le32(*buf32));
> + if (ret)
> + goto done_proc;
> +
> ++buf32;
> }
> }
> if (remaining_bytes) {
> value = 0;
> memcpy(, (u8 *)buf32, remaining_bytes);
> - hid_set_field(report->field[field_index], i,
> - (__force __s32)cpu_to_le32(value));
> + ret = hid_set_field(report->field[field_index], i,
> + (__force __s32)cpu_to_le32(value));
> + if (ret)
> + goto done_proc;
> }
> hid_hw_request(hsdev->hdev, report, HID_REQ_SET_REPORT);
> hid_hw_wait(hsdev->hdev);
Re: [PATCH v1 6/7] iio: st_sensors: Add lsm9ds0 IMU support
On Wed, 14 Apr 2021 22:54:53 +0300
Andy Shevchenko wrote:
> We can utilize separate drivers for accelerometer and magnetometer,
> so here is the glue driver to enable LSM9DS0 IMU support.
>
> The idea was suggested by Crestez Dan Leonard in [1]. The proposed change
> was sent as RFC due to race condition concerns, which are indeed possible.
If you are going to mention races, good to give some flavour in here!
This driver makes me very nervous indeed. I haven't 'found' any places
where the fact we'll write the same registers from each of the drivers
causes problems (e.g. int pin setup etc) but perhaps I'm missing something.
Shall we say that makes me rather keener to get eyes (and thought) on this
patch than normal :)
>
> In order to amend the initial change, I went further by providing a specific
> multi-instantiate probe driver that reuses existing accelerometer and
> magnetometer.
>
> [1]: https://lore.kernel.org/patchwork/patch/670353/
>
> Suggested-by: Crestez Dan Leonard
> Cc: mr.laho...@laposte.net
> Cc: Matija Podravec
> Cc: Sergey Borishchenko
> Signed-off-by: Andy Shevchenko
A few comments in here, though mostly about stuff related to the origin code
you are copying so perhaps not tidying them up is preferable because it would
complicate comparison of the two cases.
> ---
> drivers/iio/accel/st_accel_core.c| 89 +-
> drivers/iio/imu/Kconfig | 1 +
> drivers/iio/imu/Makefile | 1 +
> drivers/iio/imu/st_lsm9ds0/Kconfig | 28
> drivers/iio/imu/st_lsm9ds0/Makefile | 5 +
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0.h | 23 +++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_core.c | 163 +++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_i2c.c | 84 ++
> drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_spi.c | 83 ++
> drivers/iio/magnetometer/st_magn_core.c | 98 +++
> include/linux/iio/common/st_sensors.h| 2 +
> 11 files changed, 576 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iio/imu/st_lsm9ds0/Kconfig
> create mode 100644 drivers/iio/imu/st_lsm9ds0/Makefile
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0.h
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_core.c
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_i2c.c
> create mode 100644 drivers/iio/imu/st_lsm9ds0/st_lsm9ds0_spi.c
>
> diff --git a/drivers/iio/accel/st_accel_core.c
> b/drivers/iio/accel/st_accel_core.c
> index 5c258c1ca62d..dc32ebefe3fc 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -980,7 +980,94 @@ static const struct st_sensor_settings
> st_accel_sensors_settings[] = {
> .multi_read_bit = true,
> .bootime = 2,
> },
> -
> + {
> + .wai = 0x49,
> + .wai_addr = ST_SENSORS_DEFAULT_WAI_ADDRESS,
> + .sensors_supported = {
> + [0] = LSM9DS0_IMU_DEV_NAME,
What does the name attribute report for these?
Previously we've had the _accel etc postfix to differentiate the devices. I
don't
suppose it matters to much though as easy enough to identify the accelerometer
etc from what channels are present.
Of course driver may get name from somewhere different anyway, I haven't
checked,
just noticed this was different and wondered what the affect might be.
>
> /* Default accel DRDY is available on INT1 pin */
> diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> index f02883b08480..001ca2c3ff95 100644
> --- a/drivers/iio/imu/Kconfig
> +++ b/drivers/iio/imu/Kconfig
> @@ -94,6 +94,7 @@ config KMX61
> source "drivers/iio/imu/inv_icm42600/Kconfig"
> source "drivers/iio/imu/inv_mpu6050/Kconfig"
> source "drivers/iio/imu/st_lsm6dsx/Kconfig"
> +source "drivers/iio/imu/st_lsm9ds0/Kconfig"
>
> endmenu
>
> diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile
> index 13e9ff442b11..c82748096c77 100644
> --- a/drivers/iio/imu/Makefile
> +++ b/drivers/iio/imu/Makefile
> @@ -26,3 +26,4 @@ obj-y += inv_mpu6050/
> obj-$(CONFIG_KMX61) += kmx61.o
>
> obj-y += st_lsm6dsx/
> +obj-y += st_lsm9ds0/
> diff --git a/drivers/iio/imu/st_lsm9ds0/Kconfig
> b/drivers/iio/imu/st_lsm9ds0/Kconfig
> new file mode 100644
> index ..53b7017014f8
> --- /dev/null
> +++ b/drivers/iio/imu/st_lsm9ds0/Kconfig
> @@ -0,0 +1,28 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +config IIO_ST_LSM9DS0
> + tristate "STMicroelectronics LSM9DS0 IMU driver"
> + depends on (I2C || SPI_MASTER) && SYSFS
> + depends on !SENSORS_LIS3_I2C
> + depends on !SENSORS_LIS3_SPI
> + select IIO_ST_LSM9DS0_I2C if I2C
> + select IIO_ST_LSM9DS0_SPI if SPI_MASTER
> + select IIO_ST_ACCEL_3AXIS
> + select IIO_ST_MAGN_3AXIS
> +
> + help
> + Say yes here to build support for STMicroelectronics LSM9DS0 IMU
> + sensor. Supported devices: accelerometer/magnetometer of lsm9ds0.
> +
>
Re: [PATCH v1 4/7] iio: st_sensors: Call st_sensors_power_enable() from bus drivers
On Wed, 14 Apr 2021 22:54:51 +0300
Andy Shevchenko wrote:
> In case we would initialize two IIO devices from one physical device,
> we shouldn't have a clash on regulators. That's why move
> st_sensors_power_enable() call from core to bus drivers.
Why is this a problem? The two instances would double up and both get +
enable + disable the regulators. However, that shouldn't matter as
they are reference counted anyway.
Perhaps an example? Even in patch 6 I can only see that it is wasteful
to do it twice, rather than wrong as such.
Jonathan
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/iio/accel/st_accel_core.c | 21 +
> drivers/iio/accel/st_accel_i2c.c| 17 +++--
> drivers/iio/accel/st_accel_spi.c| 17 +++--
> drivers/iio/gyro/st_gyro_core.c | 15 +++
> drivers/iio/gyro/st_gyro_i2c.c | 17 +++--
> drivers/iio/gyro/st_gyro_spi.c | 17 +++--
> drivers/iio/magnetometer/st_magn_core.c | 15 +++
> drivers/iio/magnetometer/st_magn_i2c.c | 14 +-
> drivers/iio/magnetometer/st_magn_spi.c | 14 +-
> drivers/iio/pressure/st_pressure_core.c | 15 +++
> drivers/iio/pressure/st_pressure_i2c.c | 17 +++--
> drivers/iio/pressure/st_pressure_spi.c | 17 +++--
> 12 files changed, 130 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/iio/accel/st_accel_core.c
> b/drivers/iio/accel/st_accel_core.c
> index a1bd7e3b912e..5c258c1ca62d 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -1260,13 +1260,9 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->info = _info;
>
> - err = st_sensors_power_enable(indio_dev);
> - if (err)
> - return err;
> -
> err = st_sensors_verify_id(indio_dev);
> if (err < 0)
> - goto st_accel_power_off;
> + return err;
>
> adata->num_data_channels = ST_ACCEL_NUMBER_DATA_CHANNELS;
> indio_dev->num_channels = ST_SENSORS_NUMBER_ALL_CHANNELS;
> @@ -1275,10 +1271,8 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
> channels = devm_kmemdup(_dev->dev,
> adata->sensor_settings->ch,
> channels_size, GFP_KERNEL);
> - if (!channels) {
> - err = -ENOMEM;
> - goto st_accel_power_off;
> - }
> + if (!channels)
> + return -ENOMEM;
>
> if (apply_acpi_orientation(indio_dev, channels))
> dev_warn(_dev->dev,
> @@ -1293,11 +1287,11 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
>
> err = st_sensors_init_sensor(indio_dev, pdata);
> if (err < 0)
> - goto st_accel_power_off;
> + return err;
>
> err = st_accel_allocate_ring(indio_dev);
> if (err < 0)
> - goto st_accel_power_off;
> + return err;
>
> if (adata->irq > 0) {
> err = st_sensors_allocate_trigger(indio_dev,
> @@ -1320,9 +1314,6 @@ int st_accel_common_probe(struct iio_dev *indio_dev)
> st_sensors_deallocate_trigger(indio_dev);
> st_accel_probe_trigger_error:
> st_accel_deallocate_ring(indio_dev);
> -st_accel_power_off:
> - st_sensors_power_disable(indio_dev);
> -
> return err;
> }
> EXPORT_SYMBOL(st_accel_common_probe);
> @@ -1331,8 +1322,6 @@ void st_accel_common_remove(struct iio_dev *indio_dev)
> {
> struct st_sensor_data *adata = iio_priv(indio_dev);
>
> - st_sensors_power_disable(indio_dev);
> -
> iio_device_unregister(indio_dev);
> if (adata->irq > 0)
> st_sensors_deallocate_trigger(indio_dev);
> diff --git a/drivers/iio/accel/st_accel_i2c.c
> b/drivers/iio/accel/st_accel_i2c.c
> index 360e16f2cadb..95e305b88d5e 100644
> --- a/drivers/iio/accel/st_accel_i2c.c
> +++ b/drivers/iio/accel/st_accel_i2c.c
> @@ -174,16 +174,29 @@ static int st_accel_i2c_probe(struct i2c_client *client)
> if (ret < 0)
> return ret;
>
> + ret = st_sensors_power_enable(indio_dev);
> + if (ret)
> + return ret;
> +
> ret = st_accel_common_probe(indio_dev);
> if (ret < 0)
> - return ret;
> + goto st_accel_power_off;
>
> return 0;
> +
> +st_accel_power_off:
> + st_sensors_power_disable(indio_dev);
> +
> + return ret;
> }
>
> static int st_accel_i2c_remove(struct i2c_client *client)
> {
> - st_accel_common_remove(i2c_get_clientdata(client));
> + struct iio_dev *indio_dev = i2c_get_clientdata(client);
> +
> + st_sensors_power_disable(indio_dev);
> +
> + st_accel_common_remove(indio_dev);
>
> return 0;
> }
> diff --git a/drivers/iio/accel/st_accel_spi.c
> b/drivers/iio/accel/st_accel_spi.c
> index 568ff1bae0ee..83d3308ce5cc 100644
> ---
Re: [PATCH] iio: hid-sensors: select IIO_TRIGGERED_BUFFER under HID_SENSOR_IIO_TRIGGER
On Thu, 15 Apr 2021 09:58:33 -0700
Srinivas Pandruvada wrote:
> On Wed, 2021-04-14 at 11:49 +0300, Alexandru Ardelean wrote:
> > During commit 067fda1c065ff ("iio: hid-sensors: move triggered buffer
> > setup into hid_sensor_setup_trigger"), the
> > iio_triggered_buffer_{setup,cleanup}() functions got moved under the
> > hid-sensor-trigger module.
> >
> > The above change works fine, if any of the sensors get built.
> > However, when
> > only the common hid-sensor-trigger module gets built (and none of the
> > drivers), then the IIO_TRIGGERED_BUFFER symbol isn't
> > selected/enforced.
> >
> > Previously, each driver would enforce/select the IIO_TRIGGERED_BUFFER
> > symbol. With this change the HID_SENSOR_IIO_TRIGGER (for the
> > hid-sensor-trigger module) will enforce that IIO_TRIGGERED_BUFFER
> > gets
> > selected.
> >
> > All HID sensor drivers select the HID_SENSOR_IIO_TRIGGER symbol. So,
> > this
> > change removes the IIO_TRIGGERED_BUFFER enforcement from each driver.
> >
> > Fixes: 067fda1c065ff ("iio: hid-sensors: move triggered buffer setup
> > into hid_sensor_setup_trigger")
> > Reported-by: Thomas Deutschmann
> > Cc: Srinivas Pandruvada
> > Signed-off-by: Alexandru Ardelean
> Acked-by: Srinivas Pandruvada
Applied to the fixes-togreg branch of iio.git.
Always good to see the autobuilders can find corners no one sane would ever
hit :)
Jonathan
>
> > ---
> > drivers/iio/accel/Kconfig | 1 -
> > drivers/iio/common/hid-sensors/Kconfig | 1 +
> > drivers/iio/gyro/Kconfig | 1 -
> > drivers/iio/humidity/Kconfig | 1 -
> > drivers/iio/light/Kconfig | 2 --
> > drivers/iio/magnetometer/Kconfig | 1 -
> > drivers/iio/orientation/Kconfig| 2 --
> > drivers/iio/pressure/Kconfig | 1 -
> > drivers/iio/temperature/Kconfig| 1 -
> > 9 files changed, 1 insertion(+), 10 deletions(-)
> >
> > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> > index cceda3cecbcf..8b1723635cce 100644
> > --- a/drivers/iio/accel/Kconfig
> > +++ b/drivers/iio/accel/Kconfig
> > @@ -229,7 +229,6 @@ config DMARD10
> > config HID_SENSOR_ACCEL_3D
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > tristate "HID Accelerometers 3D"
> > diff --git a/drivers/iio/common/hid-sensors/Kconfig
> > b/drivers/iio/common/hid-sensors/Kconfig
> > index 24d492567336..2a3dd3b907be 100644
> > --- a/drivers/iio/common/hid-sensors/Kconfig
> > +++ b/drivers/iio/common/hid-sensors/Kconfig
> > @@ -19,6 +19,7 @@ config HID_SENSOR_IIO_TRIGGER
> > tristate "Common module (trigger) for all HID Sensor IIO
> > drivers"
> > depends on HID_SENSOR_HUB && HID_SENSOR_IIO_COMMON &&
> > IIO_BUFFER
> > select IIO_TRIGGER
> > + select IIO_TRIGGERED_BUFFER
> > help
> > Say yes here to build trigger support for HID sensors.
> > Triggers will be send if all requested attributes were read.
> > diff --git a/drivers/iio/gyro/Kconfig b/drivers/iio/gyro/Kconfig
> > index 5824f2edf975..20b5ac7ab66a 100644
> > --- a/drivers/iio/gyro/Kconfig
> > +++ b/drivers/iio/gyro/Kconfig
> > @@ -111,7 +111,6 @@ config FXAS21002C_SPI
> > config HID_SENSOR_GYRO_3D
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > tristate "HID Gyroscope 3D"
> > diff --git a/drivers/iio/humidity/Kconfig
> > b/drivers/iio/humidity/Kconfig
> > index 6549fcf6db69..2de5494e7c22 100644
> > --- a/drivers/iio/humidity/Kconfig
> > +++ b/drivers/iio/humidity/Kconfig
> > @@ -52,7 +52,6 @@ config HID_SENSOR_HUMIDITY
> > tristate "HID Environmental humidity sensor"
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > help
> > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> > index 33ad4dd0b5c7..917f9becf9c7 100644
> > --- a/drivers/iio/light/Kconfig
> > +++ b/drivers/iio/light/Kconfig
> > @@ -256,7 +256,6 @@ config ISL29125
> > config HID_SENSOR_ALS
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > tristate "HID ALS"
> > @@ -270,7 +269,6 @@ config HID_SENSOR_ALS
> > config HID_SENSOR_PROX
> > depends on HID_SENSOR_HUB
> > select IIO_BUFFER
> > - select IIO_TRIGGERED_BUFFER
> > select HID_SENSOR_IIO_COMMON
> > select HID_SENSOR_IIO_TRIGGER
> > tristate "HID PROX"
> > diff --git a/drivers/iio/magnetometer/Kconfig
> > b/drivers/iio/magnetometer/Kconfig
> > index 5d4ffd66032e..74ad5701c6c2 100644
> > --- a/drivers/iio/magnetometer/Kconfig
> > +++ b/drivers/iio/magnetometer/Kconfig
> > @@ -95,7 +95,6 @@ config MAG3110
> > config
Re: [PATCH v2 1/1] iio: adc: ad7298: Enable on Intel Galileo Gen 1
On Mon, 12 Apr 2021 16:18:35 +0300
Andy Shevchenko wrote:
> Enable ADC on Intel Galileo Gen 1 board.
>
> Signed-off-by: Andy Shevchenko
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to hopefully not notice we did anything ;)
Jonathan
> ---
> v2: fixed typo in ID
> drivers/iio/adc/ad7298.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/adc/ad7298.c b/drivers/iio/adc/ad7298.c
> index 689ecd5dd563..e7e866433090 100644
> --- a/drivers/iio/adc/ad7298.c
> +++ b/drivers/iio/adc/ad7298.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -352,6 +353,12 @@ static int ad7298_probe(struct spi_device *spi)
> return devm_iio_device_register(>dev, indio_dev);
> }
>
> +static const struct acpi_device_id ad7298_acpi_ids[] = {
> + { "INT3494", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, ad7298_acpi_ids);
> +
> static const struct spi_device_id ad7298_id[] = {
> {"ad7298", 0},
> {}
> @@ -361,6 +368,7 @@ MODULE_DEVICE_TABLE(spi, ad7298_id);
> static struct spi_driver ad7298_driver = {
> .driver = {
> .name = "ad7298",
> + .acpi_match_table = ad7298_acpi_ids,
> },
> .probe = ad7298_probe,
> .id_table = ad7298_id,
Re: [PATCH 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Fri, 16 Apr 2021 15:21:14 +0300 Tomas Melin wrote: > Updated email-address for Alexandru. > > > On 4/16/21 3:17 PM, Tomas Melin wrote: > > On 4/15/21 11:41 AM, Tomas Melin wrote: > > > >> > >> While working on updates I did notice something new which I cannot > >> > >> reproduce on older (5.10.17 kernel) version. If compiling this as a > >> module, getting error while > >> > >> unloading module: > >> > >> [ 40.200084] Unable to handle kernel NULL pointer dereference at > >> virtual address 0104 > >> ... > >> > >> [ 40.510054] Backtrace: > >> [ 40.512502] [] (iio_device_ioctl_handler_unregister) > >> from [] (iio_buffers_free_sysfs_and_mask+0x2c/0x6c) > >> [ 40.523735] [] (iio_buffers_free_sysfs_and_mask) from > >> [] (iio_device_unregister+0xa8/0xac) > >> [ 40.533746] r5:c1811228 r4:c1811000 > >> [ 40.537318] [] (iio_device_unregister) from [] > >> (devm_iio_device_unreg+0x1c/0x20) > >> [ 40.546461] r5:c2415000 r4:c25bab80 > >> [ 40.550025] [] (devm_iio_device_unreg) from [] > >> (release_nodes+0x1c0/0x1f0) > >> [ 40.558654] [] (release_nodes) from [] > >> (devres_release_all+0x40/0x60) > >> [ 40.566847] r10:0081 r9:c235 r8:c0100264 r7:0081 > >> r6:bf00c010 r5:c19be000 > >> [ 40.574669] r4:c1a91c00 > >> [ 40.577194] [] (devres_release_all) from [] > >> (device_release_driver_internal+0x120/0x1cc) > >> [ 40.587031] r5:c19be000 r4:c1a91c00 > >> [ 40.590596] [] (device_release_driver_internal) from > >> [] (driver_detach+0x54/0x90) > >> [ 40.599828] r7:0081 r6: r5:bf00c010 r4:c1a91c00 > >> [ 40.605482] [] (driver_detach) from [] > >> (bus_remove_driver+0x5c/0xb0) > >> [ 40.613583] r5:0800 r4:bf00c010 > >> [ 40.617148] [] (bus_remove_driver) from [] > >> (driver_unregister+0x38/0x5c) > >> [ 40.625596] r5:0800 r4:bf00c010 > >> [ 40.629161] [] (driver_unregister) from [] > >> (sca3300_driver_exit+0x14/0x8b4 [sca3300]) > >> [ 40.638747] r5:0800 r4:bf00c080 > >> [ 40.642311] [] (sca3300_driver_exit [sca3300]) from > >> [] (sys_delete_module+0x16c/0x238) > >> [ 40.651990] [] (sys_delete_module) from [] > >> (__sys_trace_return+0x0/0x1c) > >> [ 40.660435] Exception stack(0xc2351fa8 to 0xc2351ff0) > >> [ 40.665484] 1fa0: 0050e5a8 0050e5e4 > >> 0800 081d4b00 bec18af4 > >> [ 40.673661] 1fc0: 0050e5a8 bec18b50 0081 bec18e51 > >> 0050e190 0001 bec18d3c > >> [ 40.681834] 1fe0: 0050cf70 bec18afc 004f1ec8 b6ecb27c > >> [ 40.686887] r6:bec18b50 r5: r4:0050e5a8 > >> [ 40.691507] Code: e8bd4000 e1c020d0 e3a0cc01 e3001122 (e5823004) > >> [ 40.707675] ---[ end trace 189882b050077333 ]--- > >> > >> This happens when building against linux-next > >> 5.12.0-rc6-next-20210409. I'm failing to see what is wrong. Any ideas? > >> > >> Thanks, > >> > >> Tomas > > > > > > Tested further that for this driver, loading and unloading as module > > works fine until commit: > > > > commit f73f7f4da581875f9b1f2fb8ebd1ab15ed634488 > > Author: Alexandru Ardelean > > Date: Mon Feb 15 12:40:39 2021 +0200 > > > > iio: buffer: add ioctl() to support opening extra buffers for IIO > > device > > > > > > Any thoughts what causes this issue? Is this still happening after fixing the ordering in probe / remove? (devm_iio_triggered_buffer_setup() being easiest way) As driver currently stands it's calling iio_triggered_buffer_cleanup before the managed cleanup of the iio_device_register() call. That should never happen so would be where I'd look for problems here. It is possible Alex's work is relying on that ordering being correct a little more than we previously were. I could be wrong though and could be something else going on! Jonathan +CC Alex's other email address. > > > > Thanks, > > > > Tomas > > > > > > > >> > >> > >>> > --- > drivers/iio/accel/Kconfig | 13 ++ > drivers/iio/accel/Makefile | 1 + > drivers/iio/accel/sca3300.c | 434 > > 3 files changed, 448 insertions(+) > create mode 100644 drivers/iio/accel/sca3300.c > > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig > index cceda3cecbcf..0dbf7b648e8a 100644 > --- a/drivers/iio/accel/Kconfig > +++ b/drivers/iio/accel/Kconfig > @@ -450,6 +450,19 @@ config SCA3000 > To compile this driver as a module, say M here: the module > will be > called sca3000. > +config SCA3300 > + tristate "Murata SCA3300 3-Axis Accelerometer Driver" > + depends on SPI > + select CRC8 > + select IIO_BUFFER > + select IIO_TRIGGERED_BUFFER > + help > + Say yes here to build support for Murata SCA3300 3-Axis > + accelerometer. > + > + To compile this driver as a module, choose M here: the > module will be > + called sca3300. > + >
Re: [PATCH v4 2/2] iio: temperature: add driver support for ti tmp117
On Sun, 11 Apr 2021 21:08:29 +0300 Andy Shevchenko wrote: > On Sun, Apr 11, 2021 at 9:07 PM Andy Shevchenko > wrote: > > On Sun, Apr 11, 2021 at 5:53 PM Jonathan Cameron wrote: > > > On Wed, 7 Apr 2021 23:51:47 +0530 > > > Puranjay Mohan wrote: > > > Good point, but better is to use clamp_t(s16, ...) rather than explicit > > casting. > > Sorry, I meant clamp_t(int, ...) of course, otherwise it will give wrong > values. I've switched it over to this which is indeed nicer. Jonathan > > > I always consider explicit casting in C (and esp. in Linux kernel) is > > a red flag. Should be really rarely needed. > > >
Re: [PATCH] [v2] iio: proximity: pulsedlight: Fix rumtime PM imbalance on error
On Mon, 12 Apr 2021 12:23:43 +0300
Andy Shevchenko wrote:
> On Mon, Apr 12, 2021 at 8:32 AM Dinghao Liu wrote:
> >
> > When lidar_write_control() fails, a pairing PM usage counter
> > decrement is needed to keep the counter balanced.
>
> You forgot to collect given tags.
>
> > Fixes: 4ac4e086fd8c5 ("iio: pulsedlight-lidar-lite: add runtime PM")
> > Signed-off-by: Dinghao Liu
I gathered up the tags by hand and applied to the fixes-togreg branch of iio.git
Thanks,
Jonathan
> > ---
> >
> > Changelog:
> >
> > v2: - Add the fix tag.
> > ---
> > drivers/iio/proximity/pulsedlight-lidar-lite-v2.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> > b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> > index c685f10b5ae4..cc206bfa09c7 100644
> > --- a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> > +++ b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> > @@ -160,6 +160,7 @@ static int lidar_get_measurement(struct lidar_data
> > *data, u16 *reg)
> > ret = lidar_write_control(data, LIDAR_REG_CONTROL_ACQUIRE);
> > if (ret < 0) {
> > dev_err(>dev, "cannot send start measurement
> > command");
> > + pm_runtime_put_noidle(>dev);
> > return ret;
> > }
> >
> > --
> > 2.17.1
> >
>
>
Re: [PATCH] iio: light: gp2ap002: Fix rumtime PM imbalance on error
On Mon, 12 Apr 2021 13:47:58 +0200 Linus Walleij wrote: > On Mon, Apr 12, 2021 at 12:16 PM Jonathan Cameron > wrote: > > > An example would be the bmc150_magn driver which does exactly the > > same call sequence as this one, but without the reference count increment > > and decrement. Basically I want to know if there is a problem in > > those other drivers that is being protected against here! > > The bmc150_magn driver does not look like I would have done it. > > That said, I think it works, because the only thing it is calling is > bmc150_magn_set_power_mode() and that seems stateless, > just poking some regmap bits. The state is tracked by the driver > AFAICT and we don't need pm_runtime_get_noresume() because > it doesn't really matter if the pm_runtime_suspend() callback > gets called immediately or randomly out of sync with what we are > doing from this point. > > I would anyways patch it like the gp2ap002 driver because it > is easier to follow the code. Including using only runtime PM > att setting SET_SYSTEM_SLEEP_PM_OPS() to the > pm_runtime_force_suspend and pm_runtime_force_resume > functions, everything just get so much easier when you use > only one type of PM and not two orthogonal ones. > > drivers/iio/light/bh1780.c > should be a good example of how to do it idiomatically > because it was reviewed by Ulf Hansson who knows this > runtime PM stuff better than me. > > A sequence like this: > >pm_runtime_get_noresume(>dev); >pm_runtime_set_active(>dev); >pm_runtime_enable(>dev); >pm_runtime_set_autosuspend_delay(>dev, 5000); >pm_runtime_use_autosuspend(>dev); >pm_runtime_put(>dev); > > is very nice because you can clearly see that it will not race > and after the last put() unless something happens the > runtime suspend will kick in after 5000 ms. > > Likewise when disabling: > > pm_runtime_get_sync(>dev); > pm_runtime_put_noidle(>dev); > pm_runtime_disable(>dev); > > same thing: crystal clear there are no races, the device is > definately runtime resumed and we can proceed to > shut down resources explicitly after this point. > > If you then add: > > SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, > pm_runtime_force_resume) > > Now you have ordinary sleep PM for free. It will just > force the same suspend/resume callbacks and they are > guaranteed to be race free. > > This doesn't work for everyone but surprisingly often this is > what you want. I'm still far from completely convinced that it is 'necessary' to take the reference whilst going through this sequence because there is nothing to kick off the suspend until we tell it to use autosuspend. However, I appreciate (much like taking locks in general in probe) that it makes it easy to see there is no race. Anyhow, fix is still valid either way so applied to the fixes togreg branch of iio.git with a fixes tag added to the initial introduction of the driver (which I think is where this came in). Thanks, Jonathan > > Yours, > Linus Walleij
Re: [PATCH v8 1/2] Added AMS tsl2591 driver implementation
On Fri, 16 Apr 2021 18:49:01 +0100
Joe Sandom wrote:
> Driver implementation for AMS/TAOS tsl2591 ambient light sensor.
>
> This driver supports configuration via device tree and sysfs.
> Supported channels for raw infrared light intensity,
> raw combined light intensity and illuminance in lux.
> The driver additionally supports iio events on lower and
> upper thresholds.
>
> This is a very-high sensitivity light-to-digital converter that
> transforms light intensity into a digital signal.
>
> Datasheet: https://ams.com/tsl25911#tab/documents
> Signed-off-by: Joe Sandom
Hi Joe,
I was in two minds about whether to just apply this and roll in the below
suggestions + those Andy made or whether to ask you to do a v9.
The naming and units things below are complex enough that I'm not 100% sure
I'd get the right so please take a look and clean up those last few
corners!
Thanks,
Jonathan
> ---
> Changes in v8;
> - tsl2591_write_raw() - goto after tsl2591_set_als_gain_int_time() not
> necessary
> - tsl2591_read_event_value() and tsl2591_write_event_value() - break instead
> of goto in default case
> - Introduced tsl2591_info_no_irq iio_info structure which is used when the
> interrupt is disabled.
> This variant doesn't expose anything that can't be used when the interrupt
> is disabled
> - Corrected ordering of includes for
> - Renamed TSL2591_FVAL_TO_ATIME to TSL2591_MSEC_TO_ATIME
> - Renamed TSL2591_ATIME_TO_FVAL to TSL2591_ATIME_TO_MSEC
> - Changed TSL2591_STS_ALS* defines to all use BIT for consistency
> - Use (BIT(4) - 1) instead of value from list for
> TSL2591_PRST_ALS_INT_CYCLE_MAX
> - Cleaned up a few blank lines that were unneccesary
> - Use sysfs_emit() instead of snprintf() in
> tsl2591_in_illuminance_period_available_show()
> - Use err_unlock branch instead of err to be clear on mutex_unlock cases
> - Tidied up use of goto err_unlock in tsl2591_read_raw() to be consistent
> with other functions
>
> NOTE;
> - tsl2591_set_als_lower_threshold() and tsl2591_set_als_upper_threshold()
> forward declaration needed
> because tsl2591_set_als_lower_threshold() calls
> tsl2591_set_als_upper_threshold() and vice versa
>
> drivers/iio/light/Kconfig | 11 +
> drivers/iio/light/Makefile |1 +
> drivers/iio/light/tsl2591.c | 1227 +++
> 3 files changed, 1239 insertions(+)
> create mode 100644 drivers/iio/light/tsl2591.c
>
...
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index ea376deaca54..d10912faf964 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_ST_UVIS25_SPI) += st_uvis25_spi.o
> obj-$(CONFIG_TCS3414)+= tcs3414.o
> obj-$(CONFIG_TCS3472)+= tcs3472.o
> obj-$(CONFIG_TSL2583)+= tsl2583.o
> +obj-$(CONFIG_TSL2591)+= tsl2591.o
> obj-$(CONFIG_TSL2772)+= tsl2772.o
> obj-$(CONFIG_TSL4531)+= tsl4531.o
> obj-$(CONFIG_US5182D)+= us5182d.o
> diff --git a/drivers/iio/light/tsl2591.c b/drivers/iio/light/tsl2591.c
> new file mode 100644
> index ..4f9c5e19ee35
> --- /dev/null
> +++ b/drivers/iio/light/tsl2591.c
> @@ -0,0 +1,1227 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 Joe Sandom
Update perhaps?
> + *
> + * Datasheet: https://ams.com/tsl25911#tab/documents
> + *
> + * Device driver for the TAOS TSL2591. This is a very-high sensitivity
> + * light-to-digital converter that transforms light intensity into a digital
> + * signal.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +/* ADC integration time, field value to time in ms */
> +#define TSL2591_MSEC_TO_ATIME(x) (((x) + 1) * 100)
Naming here seems backwards. I'd assume that at MSEC_TO_ATIME
function went msecs -> atime but it seems to be doing the opposite.
> +/* ADC integration time, time in ms to field value */
> +#define TSL2591_ATIME_TO_MSEC(x) (((x) / 100) - 1)
> +
...
> +
> +/*
> + * Period table is ALS persist cycle x integration time setting
> + * Integration times: 100ms, 200ms, 300ms, 400ms, 500ms, 600ms
> + * ALS cycles: 1, 2, 3, 5, 10, 20, 25, 30, 35, 40, 45, 50, 55, 60
> + */
> +static const char * const tsl2591_als_period_list[] = {
> + "0.1 0.2 0.3 0.5 1.0 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0",
> + "0.2 0.4 0.6 1.0 2.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0",
> + "0.3 0.6 0.9 1.5 3.0 6.0 7.5 9.0 10.5 12.0 13.5 15.0 16.5 18.0",
> + "0.4 0.8 1.2 2.0 4.0 8.0 10.0 12.0 14.0 16.0 18.0 20.0 22.0 24.0",
> + "0.5 1.0 1.5 2.5 5.0 10.0 12.5 15.0 17.5 20.0 22.5 25.0 27.5 30.0",
> + "0.6 1.2 1.8 3.0 6.0 12.0 15.0 18.0 21.0 24.0 27.0 30.0 33.0 36.0",
> +};
> +
> +static const int tsl2591_int_time_available[] = {
> + 100, 200, 300, 400, 500,
Re: [PATCH 21/57] staging: iio: frequency: ad9834: Provide missing description for 'devid'
On Wed, 14 Apr 2021 19:10:53 +0100
Lee Jones wrote:
> Also demote kernel-doc abuses
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/staging/iio/frequency/ad9834.c:87: warning: Function parameter or
> member 'devid' not described in 'ad9834_state'
> drivers/staging/iio/frequency/ad9834.c:93: warning: cannot understand
> function prototype: 'enum ad9834_supported_device_ids '
> drivers/staging/iio/frequency/ad9834.c:320: warning: This comment starts
> with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
>
> Cc: Lars-Peter Clausen
> Cc: Michael Hennerich
> Cc: Jonathan Cameron
> Cc: Greg Kroah-Hartman
> Cc: linux-...@vger.kernel.org
> Cc: linux-stag...@lists.linux.dev
> Signed-off-by: Lee Jones
I was leaving the staging stuff in IIO related to W=1 as good material
for newbies, but I guess if you are blanket cleaning it up then fair
enough.
Sounds like Greg will take the whole series so,
Acked-by: Jonathan Cameron
> ---
> drivers/staging/iio/frequency/ad9834.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/iio/frequency/ad9834.c
> b/drivers/staging/iio/frequency/ad9834.c
> index 60a3ae5587b90..94b131ef8a22c 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -58,6 +58,7 @@
> * @spi: spi_device
> * @mclk:external master clock
> * @control: cached control word
> + * @devid: device id
> * @xfer:default spi transfer
> * @msg: default spi message
> * @freq_xfer: tuning word spi transfer
> @@ -86,7 +87,7 @@ struct ad9834_state {
> __be16 freq_data[2];
> };
>
> -/**
> +/*
> * ad9834_supported_device_ids:
> */
>
> @@ -316,7 +317,7 @@ ssize_t ad9834_show_out1_wavetype_available(struct device
> *dev,
> static IIO_DEVICE_ATTR(out_altvoltage0_out1_wavetype_available, 0444,
> ad9834_show_out1_wavetype_available, NULL, 0);
>
> -/**
> +/*
> * see dds.h for further information
> */
>
Re: [”PATCH” 2/5] PCI: armada8k: Add link-down handle
On Mon, 12 Apr 2021 18:30:53 +0300
wrote:
> From: Ben Peled
>
> In PCIE ISR routine caused by RST_LINK_DOWN
> we schedule work to handle the link-down procedure.
> Link-down procedure will:
> 1. Remove PCIe bus
> 2. Reset the MAC
> 3. Reconfigure link back up
> 4. Rescan PCIe bus
>
> Signed-off-by: Ben Peled
Trivial comment inline.
Also, something odd with quotes around PATCH in the title you probably
want to clean up.
> ---
> drivers/pci/controller/dwc/pcie-armada8k.c | 68
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c
> b/drivers/pci/controller/dwc/pcie-armada8k.c
> index b2278b1..4eb8607 100644
> --- a/drivers/pci/controller/dwc/pcie-armada8k.c
> +++ b/drivers/pci/controller/dwc/pcie-armada8k.c
> @@ -22,6 +22,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "pcie-designware.h"
>
> @@ -33,6 +35,9 @@ struct armada8k_pcie {
> struct clk *clk_reg;
> struct phy *phy[ARMADA8K_PCIE_MAX_LANES];
> unsigned int phy_count;
> + struct regmap *sysctrl_base;
> + u32 mac_rest_bitmask;
> + struct work_struct recover_link_work;
> };
>
> #define PCIE_VENDOR_REGS_OFFSET 0x8000
> @@ -73,6 +78,8 @@ struct armada8k_pcie {
> #define AX_USER_DOMAIN_MASK 0x3
> #define AX_USER_DOMAIN_SHIFT 4
>
> +#define UNIT_SOFT_RESET_CONFIG_REG 0x268
> +
> #define to_armada8k_pcie(x) dev_get_drvdata((x)->dev)
>
> static void armada8k_pcie_disable_phys(struct armada8k_pcie *pcie)
> @@ -224,6 +231,49 @@ static int armada8k_pcie_host_init(struct pcie_port *pp)
>
> return 0;
> }
> +static void armada8k_pcie_recover_link(struct work_struct *ws)
> +{
> + struct armada8k_pcie *pcie = container_of(ws, struct armada8k_pcie,
> recover_link_work);
> + struct pcie_port *pp = >pci->pp;
> + struct pci_bus *bus = pp->bridge->bus;
> + struct pci_dev *root_port;
> + int ret;
> +
> + root_port = pci_get_slot(bus, 0);
> + if (!root_port) {
> + dev_err(pcie->pci->dev, "failed to get root port\n");
> + return;
> + }
> + pci_lock_rescan_remove();
> + pci_stop_and_remove_bus_device(root_port);
> + /*
> + * Sleep needed to make sure all pcie transactions and access
> + * are flushed before resetting the mac
> + */
> + msleep(100);
> +
> + /* Reset mac */
> + regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
> + pcie->mac_rest_bitmask, 0, NULL, false, true);
> + udelay(1);
> + regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
> + pcie->mac_rest_bitmask, pcie->mac_rest_bitmask,
> + NULL, false, true);
> + udelay(1);
> + ret = armada8k_pcie_host_init(pp);
> + if (ret) {
> + dev_err(pcie->pci->dev, "failed to initialize host: %d\n", ret);
> + pci_unlock_rescan_remove();
> + pci_dev_put(root_port);
> + return;
> + }
> +
> + bus = NULL;
> + while ((bus = pci_find_next_bus(bus)) != NULL)
> + pci_rescan_bus(bus);
> + pci_unlock_rescan_remove();
> + pci_dev_put(root_port);
> +}
>
> static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
> {
> @@ -262,6 +312,9 @@ static irqreturn_t armada8k_pcie_irq_handler(int irq,
> void *arg)
>* initiate a link retrain. If link retrains were
>* possible, that is.
>*/
> + if (pcie->sysctrl_base && pcie->mac_rest_bitmask)
> + schedule_work(>recover_link_work);
> +
> dev_dbg(pci->dev, "%s: link went down\n", __func__);
> }
>
> @@ -330,6 +383,8 @@ static int armada8k_pcie_probe(struct platform_device
> *pdev)
>
> pcie->pci = pci;
>
> + INIT_WORK(>recover_link_work, armada8k_pcie_recover_link);
> +
> pcie->clk = devm_clk_get(dev, NULL);
> if (IS_ERR(pcie->clk))
> return PTR_ERR(pcie->clk);
> @@ -357,6 +412,19 @@ static int armada8k_pcie_probe(struct platform_device
> *pdev)
> goto fail_clkreg;
> }
>
> + pcie->sysctrl_base = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> +
> "marvell,system-controller");
> + if (IS_ERR(pcie->sysctrl_base)) {
> + dev_warn(dev, "failed to find marvell,system-controller\n");
> + pcie->sysctrl_base = 0x0;
= NULL; ?
> + }
> +
> + ret = of_property_read_u32(pdev->dev.of_node,
> "marvell,mac-reset-bit-mask",
> +>mac_rest_bitmask);
> + if (ret < 0) {
> + dev_warn(dev, "couldn't find mac reset bit mask: %d\n", ret);
> + pcie->mac_rest_bitmask = 0x0;
> + }
> ret = armada8k_pcie_setup_phys(pcie);
> if (ret)
> goto fail_clkreg;
Re: [PATCH] cxl/mem: Add media provisioning required commands
On Tue, 13 Apr 2021 07:09:07 -0700
Ben Widawsky wrote:
> Some of the commands have already been defined for the support of RAW
> commands (to be blocked). Unlike their usage in the RAW interface, when
> used through the supported interface, they will be coordinated and
> marshalled along with other commands being issued by userspace and the
> driver itself. That coordination will be added later.
>
> The list of commands was determined based on the learnings from
> libnvdimm and this list is provided directly from Dan.
>
> Recommended-by: Dan Williams
> Signed-off-by: Ben Widawsky
Checked all the numbers (not much else in this one ;)
Reviewed-by: Jonathan Cameron
You could give more info on why this particular list, but to my
mind it's all fairly obvious so perhaps not worth bothering.
> ---
> drivers/cxl/mem.c| 19 +++
> include/uapi/linux/cxl_mem.h | 12
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index e915e3743b76..e3306aa560cf 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -50,7 +50,14 @@ enum opcode {
> CXL_MBOX_OP_GET_LSA = 0x4102,
> CXL_MBOX_OP_SET_LSA = 0x4103,
> CXL_MBOX_OP_GET_HEALTH_INFO = 0x4200,
> + CXL_MBOX_OP_GET_ALERT_CONFIG= 0x4201,
> + CXL_MBOX_OP_SET_ALERT_CONFIG= 0x4202,
> + CXL_MBOX_OP_GET_SHUTDOWN_STATE = 0x4203,
> CXL_MBOX_OP_SET_SHUTDOWN_STATE = 0x4204,
> + CXL_MBOX_OP_GET_POISON = 0x4300,
> + CXL_MBOX_OP_INJECT_POISON = 0x4301,
> + CXL_MBOX_OP_CLEAR_POISON= 0x4302,
> + CXL_MBOX_OP_GET_SCAN_MEDIA_CAPS = 0x4303,
> CXL_MBOX_OP_SCAN_MEDIA = 0x4304,
> CXL_MBOX_OP_GET_SCAN_MEDIA = 0x4305,
> CXL_MBOX_OP_MAX = 0x1
> @@ -158,6 +165,18 @@ static struct cxl_mem_command
> mem_commands[CXL_MEM_COMMAND_ID_MAX] = {
> CXL_CMD(GET_LSA, 0x8, ~0, 0),
> CXL_CMD(GET_HEALTH_INFO, 0, 0x12, 0),
> CXL_CMD(GET_LOG, 0x18, ~0, CXL_CMD_FLAG_FORCE_ENABLE),
> + CXL_CMD(SET_PARTITION_INFO, 0x0a, 0, 0),
> + CXL_CMD(SET_LSA, ~0, 0, 0),
> + CXL_CMD(GET_ALERT_CONFIG, 0, 0x10, 0),
> + CXL_CMD(SET_ALERT_CONFIG, 0xc, 0, 0),
> + CXL_CMD(GET_SHUTDOWN_STATE, 0, 0x1, 0),
> + CXL_CMD(SET_SHUTDOWN_STATE, 0x1, 0, 0),
> + CXL_CMD(GET_POISON, 0x10, ~0, 0),
> + CXL_CMD(INJECT_POISON, 0x8, 0, 0),
> + CXL_CMD(CLEAR_POISON, 0x48, 0, 0),
> + CXL_CMD(GET_SCAN_MEDIA_CAPS, 0x10, 0x4, 0),
> + CXL_CMD(SCAN_MEDIA, 0x11, 0, 0),
> + CXL_CMD(GET_SCAN_MEDIA, 0, ~0, 0),
> };
>
> /*
> diff --git a/include/uapi/linux/cxl_mem.h b/include/uapi/linux/cxl_mem.h
> index 3155382dfc9b..f6e8a005b113 100644
> --- a/include/uapi/linux/cxl_mem.h
> +++ b/include/uapi/linux/cxl_mem.h
> @@ -29,6 +29,18 @@
> ___C(GET_LSA, "Get Label Storage Area"), \
> ___C(GET_HEALTH_INFO, "Get Health Info"), \
> ___C(GET_LOG, "Get Log"), \
> + ___C(SET_PARTITION_INFO, "Set Partition Information"),\
> + ___C(SET_LSA, "Set Label Storage Area"), \
> + ___C(GET_ALERT_CONFIG, "Get Alert Configuration"),\
> + ___C(SET_ALERT_CONFIG, "Set Alert Configuration"),\
> + ___C(GET_SHUTDOWN_STATE, "Get Shutdown State"), \
> + ___C(SET_SHUTDOWN_STATE, "Set Shutdown State"), \
> + ___C(GET_POISON, "Get Poison List"), \
> + ___C(INJECT_POISON, "Inject Poison"), \
> + ___C(CLEAR_POISON, "Clear Poison"), \
> + ___C(GET_SCAN_MEDIA_CAPS, "Get Scan Media Capabilities"), \
> + ___C(SCAN_MEDIA, "Scan Media"), \
> + ___C(GET_SCAN_MEDIA, "Get Scan Media Results"), \
> ___C(MAX, "invalid / last command")
>
> #define ___C(a, b) CXL_MEM_COMMAND_ID_##a
Re: [PATCH] cxl/mem: Clarify UAPI documentation
On Tue, 13 Apr 2021 07:32:47 -0700
Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
Sensible update.
Acked-by: Jonathan Cameron
> ---
> include/uapi/linux/cxl_mem.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/uapi/linux/cxl_mem.h b/include/uapi/linux/cxl_mem.h
> index f6e8a005b113..8dd516ddb098 100644
> --- a/include/uapi/linux/cxl_mem.h
> +++ b/include/uapi/linux/cxl_mem.h
> @@ -81,6 +81,13 @@ static const struct {
> * - @size_in = -1
> * - @size_out = 0
> *
> + * Commands which have a variable length input likely have a minimum length.
> + * This is not enforced by the UAPI, and therefore might look like the
> command
> + * succeeded when sending too small of an input payload. Caution should be
> taken
> + * by checking the @cxl_send_command.retval for such cases. For commands
> with a
> + * variable length output, the caller is free to consume as little or as
> much as
> + * they want.
> + *
> * See struct cxl_mem_query_commands.
> */
> struct cxl_command_info {
Re: [PATCH 4/7] cxl/mem: Get rid of @cxlm.base
On Tue, 13 Apr 2021 09:17:26 -0700
Ben Widawsky wrote:
> On 21-04-08 18:26:35, Jonathan Cameron wrote:
> > On Wed, 7 Apr 2021 15:26:22 -0700
> > Ben Widawsky wrote:
> >
> > > @cxlm.base only existed to support holding the base found in the
> > > register block mapping code, and pass it along to the register setup
> > > code. Now that the register setup function has all logic around managing
> > > the registers, from DVSEC to iomapping up to populating our CXL specific
> > > information, it is easy to turn the @base values into local variables
> > > and remove them from our device driver state.
> > >
> > > Signed-off-by: Ben Widawsky
> >
> > Patch is basically fine, but I do wonder if you could avoid the
> > nasty casting in and out of __iomem in the error paths.
> >
> > It's a common enough idiom though so I'm not htat fussed.
> >
> > Acked-by: Jonathan Cameron
> >
> > > ---
> > > drivers/cxl/mem.c | 24 +++-
> > > drivers/cxl/mem.h | 2 --
> > > 2 files changed, 11 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > > index 04b4f7445083..60b95c524c3e 100644
> > > --- a/drivers/cxl/mem.c
> > > +++ b/drivers/cxl/mem.c
> > > @@ -922,11 +922,10 @@ static struct cxl_mem *cxl_mem_create(struct
> > > pci_dev *pdev)
> > > return cxlm;
> > > }
> > >
> > > -static int cxl_mem_map_regblock(struct cxl_mem *cxlm, u32 reg_lo, u32
> > > reg_hi)
> > > +static void __iomem *cxl_mem_map_regblock(struct cxl_mem *cxlm, u32
> > > reg_lo, u32 reg_hi)
> > > {
> > > struct pci_dev *pdev = cxlm->pdev;
> > > struct device *dev = >dev;
> > > - void __iomem *regs;
> > > u64 offset;
> > > u8 bar;
> > > int rc;
> > > @@ -938,20 +937,18 @@ static int cxl_mem_map_regblock(struct cxl_mem
> > > *cxlm, u32 reg_lo, u32 reg_hi)
> > > if (pci_resource_len(pdev, bar) < offset) {
> > > dev_err(dev, "BAR%d: %pr: too small (offset: %#llx)\n", bar,
> > > >resource[bar], (unsigned long long)offset);
> > > - return -ENXIO;
> > > + return (void __iomem *)ERR_PTR(-ENXIO);
> > > }
> > >
> > > rc = pcim_iomap_regions(pdev, BIT(bar), pci_name(pdev));
> > > if (rc) {
> > > dev_err(dev, "failed to map registers\n");
> > > - return rc;
> > > + return (void __iomem *)ERR_PTR(rc);
> >
> > The casting is fairly horrible, perhaps just pass in
> > a void __iomem ** and pass base back through that?
> >
>
> TIL: IOMEM_ERR_PTR. Would that suffice?
Definitely. Didn't know about that!
Jonathan
Re: [PATCH v2 1/8] cxl/mem: Move some definitions to mem.h
On Tue, 13 Apr 2021 17:42:37 -0700 Dan Williams wrote: > On Tue, Apr 13, 2021 at 5:18 PM Dan Williams wrote: > > > > On Tue, Apr 6, 2021 at 10:47 AM Jonathan Cameron > > wrote: > > > > > > On Thu, 1 Apr 2021 07:30:47 -0700 > > > Dan Williams wrote: > > > > > > > In preparation for sharing cxl.h with other generic CXL consumers, > > > > move / consolidate some of the memory device specifics to mem.h. > > > > > > > > Reviewed-by: Ben Widawsky > > > > Signed-off-by: Dan Williams > > > > > > Hi Dan, > > > > > > Would be good to see something in this patch description saying > > > why you chose to have mem.h rather than push the defines down > > > into mem.c (which from the current code + patch set looks like > > > the more logical thing to do). > > > > The main motivation was least privilege access to memory-device > > details, so they had to move out of cxl.h. As to why move them in to a > > new mem.h instead of piling more into mem.c that's just a personal > > organizational style choice to aid review. I tend to go to headers > > first and read data structure definitions before reading the > > implementation, and having that all in one place is cleaner than > > interspersed with implementation details in the C code. It's all still > > private to drivers/cxl/ so I don't see any "least privilege" concerns > > with moving it there. > > > > Does that satisfy your concern? > > > > If yes, I'll add the above to v3. > > Oh, another thing it helps is the information content of diffstats to > distinguish definition changes from implementation development. I go the other way style wise, but agree it doesn't really matter for local headers included from few other files. Adding a above to comment will at least avoid anyone else (or forgetful me) raising question on v3. Jonathan
Re: [RFC PATCH v1 00/11] Manage the top tier memory in a tiered memory
On Mon, 12 Apr 2021 12:20:22 -0700
Shakeel Butt wrote:
> On Fri, Apr 9, 2021 at 4:26 PM Tim Chen wrote:
> >
> >
> > On 4/8/21 4:52 AM, Michal Hocko wrote:
> >
> > >> The top tier memory used is reported in
> > >>
> > >> memory.toptier_usage_in_bytes
> > >>
> > >> The amount of top tier memory usable by each cgroup without
> > >> triggering page reclaim is controlled by the
> > >>
> > >> memory.toptier_soft_limit_in_bytes
> > >
> >
> > Michal,
> >
> > Thanks for your comments. I will like to take a step back and
> > look at the eventual goal we envision: a mechanism to partition the
> > tiered memory between the cgroups.
> >
> > A typical use case may be a system with two set of tasks.
> > One set of task is very latency sensitive and we desire instantaneous
> > response from them. Another set of tasks will be running batch jobs
> > were latency and performance is not critical. In this case,
> > we want to carve out enough top tier memory such that the working set
> > of the latency sensitive tasks can fit entirely in the top tier memory.
> > The rest of the top tier memory can be assigned to the background tasks.
> >
> > To achieve such cgroup based tiered memory management, we probably want
> > something like the following.
> >
> > For generalization let's say that there are N tiers of memory t_0, t_1 ...
> > t_N-1,
> > where tier t_0 sits at the top and demotes to the lower tier.
> > We envision for this top tier memory t0 the following knobs and counters
> > in the cgroup memory controller
> >
> > memory_t0.current Current usage of tier 0 memory by the cgroup.
> >
> > memory_t0.min If tier 0 memory used by the cgroup falls below
> > this low
> > boundary, the memory will not be subjected to
> > demotion
> > to lower tiers to free up memory at tier 0.
> >
> > memory_t0.low Above this boundary, the tier 0 memory will be
> > subjected
> > to demotion. The demotion pressure will be
> > proportional
> > to the overage.
> >
> > memory_t0.high If tier 0 memory used by the cgroup exceeds this
> > high
> > boundary, allocation of tier 0 memory by the cgroup
> > will
> > be throttled. The tier 0 memory used by this cgroup
> > will also be subjected to heavy demotion.
> >
> > memory_t0.max This will be a hard usage limit of tier 0 memory on
> > the cgroup.
> >
> > If needed, memory_t[12...].current/min/low/high for additional tiers can be
> > added.
> > This follows closely with the design of the general memory controller
> > interface.
> >
> > Will such an interface looks sane and acceptable with everyone?
> >
>
> I have a couple of questions. Let's suppose we have a two socket
> system. Node 0 (DRAM+CPUs), Node 1 (DRAM+CPUs), Node 2 (PMEM on socket
> 0 along with Node 0) and Node 3 (PMEM on socket 1 along with Node 1).
> Based on the tier definition of this patch series, tier_0: {node_0,
> node_1} and tier_1: {node_2, node_3}.
>
> My questions are:
>
> 1) Can we assume that the cost of access within a tier will always be
> less than the cost of access from the tier? (node_0 <-> node_1 vs
> node_0 <-> node_2)
No in large systems even it we can make this assumption in 2 socket ones.
> 2) If yes to (1), is that assumption future proof? Will the future
> systems with DRAM over CXL support have the same characteristics?
> 3) Will the cost of access from tier_0 to tier_1 be uniform? (node_0
> <-> node_2 vs node_0 <-> node_3). For jobs running on node_0, node_3
> might be third tier and similarly for jobs running on node_1, node_2
> might be third tier.
>
> The reason I am asking these questions is that the statically
> partitioning memory nodes into tiers will inherently add platform
> specific assumptions in the user API.
Absolutely agree.
>
> Assumptions like:
> 1) Access within tier is always cheaper than across tier.
> 2) Access from tier_i to tier_i+1 has uniform cost.
>
> The reason I am more inclined towards having numa centric control is
> that we don't have to make these assumptions. Though the usability
> will be more difficult. Greg (CCed) has some ideas on making it better
> and we will share our proposal after polishing it a bit more.
>
Sounds good, will look out for that.
Jonathan
Re: [PATCH 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On Mon, 12 Apr 2021 10:50:56 +0300
Tomas Melin wrote:
> Add initial support for Murata SCA3300 3-axis industrial
> accelerometer with digital SPI interface. This device also
> provides a temperature measurement.
>
> Device product page including datasheet can be found at:
> https://www.murata.com/en-global/products/sensor/accel/sca3300
>
> Signed-off-by: Tomas Melin
Hi Tomas,
Comments below.
Thanks,
Jonathan
> ---
> drivers/iio/accel/Kconfig | 13 ++
> drivers/iio/accel/Makefile | 1 +
> drivers/iio/accel/sca3300.c | 434
> 3 files changed, 448 insertions(+)
> create mode 100644 drivers/iio/accel/sca3300.c
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index cceda3cecbcf..0dbf7b648e8a 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -450,6 +450,19 @@ config SCA3000
> To compile this driver as a module, say M here: the module will be
> called sca3000.
>
> +config SCA3300
> + tristate "Murata SCA3300 3-Axis Accelerometer Driver"
> + depends on SPI
> + select CRC8
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say yes here to build support for Murata SCA3300 3-Axis
> + accelerometer.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called sca3300.
> +
> config STK8312
> tristate "Sensortek STK8312 3-Axis Accelerometer Driver"
> depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 32cd1342a31a..4b56527a2b97 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_MXC4005) += mxc4005.o
> obj-$(CONFIG_MXC6255)+= mxc6255.o
>
> obj-$(CONFIG_SCA3000)+= sca3000.o
> +obj-$(CONFIG_SCA3300)+= sca3300.o
>
> obj-$(CONFIG_STK8312)+= stk8312.o
> obj-$(CONFIG_STK8BA50) += stk8ba50.o
> diff --git a/drivers/iio/accel/sca3300.c b/drivers/iio/accel/sca3300.c
> new file mode 100644
> index ..112fb88ecd3a
> --- /dev/null
> +++ b/drivers/iio/accel/sca3300.c
> @@ -0,0 +1,434 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Vaisala Oyj. All rights reserved.
Give a year for the copyright notice if you can.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SCA3300_ALIAS "sca3300"
> +
> +#define SCA3300_REG_STATUS 0x6
> +#define SCA3300_REG_MODE 0xd
> +#define SCA3300_REG_WHOAMI 0x10
> +#define SCA3300_VALUE_SW_RESET 0x20
> +#define SCA3300_CRC8_POLYNOMIAL 0x1d
> +#define SCA3300_X_READ 0
I wouldn't bother defining this.
> +#define SCA3300_X_WRITE BIT(7)
Even this one is something I'd just put inline with a comment.
> +#define SCA3300_DEVICE_ID 0x51
> +#define SCA3300_RS_ERROR 0x3
> +
> +enum sca3300_scan_indexes {
> + SCA3300_ACC_X = 0,
> + SCA3300_ACC_Y,
> + SCA3300_ACC_Z,
> + SCA3300_TEMP,
> + SCA3300_TIMESTAMP,
> +};
> +
> +#define SCA3300_ACCEL_CHANNEL(index, reg, axis) {\
> + .type = IIO_ACCEL, \
> + .address = reg, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_##axis, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_PROCESSED), \
As mentioned below, don't provide PROCESSED. Userspace is better at handling the
conversion so leave it to them.
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> + .scan_index = index,\
> + .scan_type = { \
> + .sign = 's',\
> + .realbits = 16, \
> + .storagebits = 16, \
> + .shift = 0, \
> + .endianness = IIO_CPU, \
> + }, \
> + }
> +
> +static const struct iio_chan_spec sca3300_channels[] = {
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_X, 0x1, X),
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_Y, 0x2, Y),
> + SCA3300_ACCEL_CHANNEL(SCA3300_ACC_Z, 0x3, Z),
> + {
> + .type = IIO_TEMP,
> + .address = 0x5,
> + .scan_index = SCA3300_TEMP,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .scan_type = {
> + .sign = 's',
> + .realbits = 16,
> +
Re: [PATCH 1/2] dt-bindings: iio: accel: Add SCA3300 documentation
On Mon, 12 Apr 2021 10:50:55 +0300
Tomas Melin wrote:
> initial DT bindings for Murata SCA3300 Accelerometer.
>
> Signed-off-by: Tomas Melin
Hi Tomas.
> ---
> .../bindings/iio/accel/sca3300.yaml | 51 +++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/sca3300.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/sca3300.yaml
> b/Documentation/devicetree/bindings/iio/accel/sca3300.yaml
> new file mode 100644
> index ..32fe4b647cd0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/sca3300.yaml
Vendor prefix on the filename please.
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0-only)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/accel/sca3300.yaml#
Vendor prefix will end up here as well.
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Murata SCA3300 Accelerometer
> +
> +description: |
> + 3-axis industrial accelerometer with digital SPI interface
> + https://www.murata.com/en-global/products/sensor/accel/sca3300
> +
> +maintainers:
> + - Tomas Melin
> +
> +properties:
> + compatible:
> +enum:
> + - murata,sca3300
> +
> + reg:
> +maxItems: 1
> +description: SPI chip select number according to the general SPI bindings
No need to give a description as this is the same for all SPI devices.
> +
> + spi-max-frequency:
> +maximum: 800
> +
> + murata,opmode:
> +description: Accelerometer operation mode as described in datasheet
> (MODE)
> +$ref: /schemas/types.yaml#/definitions/uint32
This needs a proper description here. Also perhaps worth noting that we
very rarely let mode related things like this into DT. They are always almost
something that is policy rather than hardware description and so belong
somewhere
userspace can control them.
In this particular case, looks like a simple range control. That belongs in
userspace via _scale attributes.
> +
> +required:
> + - compatible
> + - reg
> + - murata,opmode
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +spi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +sca3300@0 {
> +compatible = "murata,sca3300";
> +reg = <0x0>;
> +spi-max-frequency = <400>;
> +murata,opmode = <4>;
> +};
> +};
> +...
Re: [PATCH] HID: hid-sensor-custom: remove useless variable
On Sun, 11 Apr 2021 09:06:35 -0700
Srinivas Pandruvada wrote:
> On Sun, 2021-04-11 at 14:56 +0100, Jonathan Cameron wrote:
> > On Fri, 09 Apr 2021 11:19:12 -0700
> > Srinivas Pandruvada wrote:
> >
> > > On Fri, 2021-04-09 at 15:15 +0800, Jiapeng Chong wrote:
> > > > Fix the following gcc warning:
> > > >
> > > > drivers/hid/hid-sensor-custom.c:400:7: warning: variable ‘ret’
> > > > set
> > > > but
> > > > not used [-Wunused-but-set-variable].
> > > >
> > > > Reported-by: Abaci Robot
> > > > Signed-off-by: Jiapeng Chong
> > > Acked-by: Srinivas Pandruvada >
> > Perhaps better to return ret if it is non zero?
> > I can't immediately figure out if there is a reason we know that
> > can't
> > happen.
> Only time it can fail when there is no report descriptor or the field
> index is >= report->maxfield.
> But since the attribute is registered from the report descriptor and
> index, this can't happen.
> But we can enhance sensor_hub_set_feature() to fail when
> hid_set_field() fails. There is one case where field->logical_minimum
> < 0 and value is out of range.
I'll go with what you think. Apply as is, or handle the
return value because we might at some later date return an error that
can actually happen from here?
Jonathan
>
> Thanks,
> Srinivas
>
>
> >
> > Jonathan
> >
> > > > ---
> > > > drivers/hid/hid-sensor-custom.c | 5 ++---
> > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-
> > > > sensor-custom.c
> > > > index 2628bc5..e430673 100644
> > > > --- a/drivers/hid/hid-sensor-custom.c
> > > > +++ b/drivers/hid/hid-sensor-custom.c
> > > > @@ -397,15 +397,14 @@ static ssize_t store_value(struct device
> > > > *dev,
> > > > struct device_attribute *attr,
> > > >
> > > > if (!strncmp(name, "value", strlen("value"))) {
> > > > u32 report_id;
> > > > - int ret;
> > > >
> > > > if (kstrtoint(buf, 0, ) != 0)
> > > > return -EINVAL;
> > > >
> > > > report_id = sensor_inst->fields[field_index].attribute.
> > > > report_
> > > > id;
> > > > - ret = sensor_hub_set_feature(sensor_inst->hsdev,
> > > > report_id,
> > > > -index, sizeof(value),
> > > > );
> > > > + sensor_hub_set_feature(sensor_inst->hsdev, report_id,
> > > > index,
> > > > + sizeof(value), );
> > > > } else
> > > > return -EINVAL;
> > > >
>
Re: [PATCH] iio: light: gp2ap002: Fix rumtime PM imbalance on error
On Mon, 12 Apr 2021 00:38:41 +0200 Linus Walleij wrote: > On Sun, Apr 11, 2021 at 5:07 PM Jonathan Cameron wrote: > > On Wed, 7 Apr 2021 11:49:27 +0800 > > Dinghao Liu wrote: > > > > > When devm_request_threaded_irq() fails, we should decrease the > > > runtime PM counter to keep the counter balanced. But when > > > iio_device_register() fails, we need not to decrease it because > > > we have already decreased it before. > > > > Whilst agree with your assessment that the code is wrong, I'm not > > totally sure why we need to do the pm_runtime_get_noresume() in > > the first place. Why do we need to hold the reference for > > the operations going on here? What can race against this that > > might care about that reference count? > > pm_runtime_get_noresume() is increasing the runtime PM > reference without calling the pm_runtime_resume() callback. > > It is often called in sequence like this: > > pm_runtime_get_noresume(dev); > pm_runtime_set_active(dev); > pm_runtime_enable(dev); > > This increases the reference, sets the device as active > and enables runtime PM. > > The reason that probe() has activated resources such as > enabling two regulators, and want to leave them on so that > later on pm_runtime_suspend() will disable them, i.e. > handover to runtime PM with the device in resumed state. > > I hope this is answering the question, not sure. There are drivers that look the same except they aren't holding the reference. Are those immediately disabling the power? I can't see the path by which that happens, but perhaps I'm just missing something? Maybe this is just paranoid locking in a probe path (before we are in a position where races can occur)? An example would be the bmc150_magn driver which does exactly the same call sequence as this one, but without the reference count increment and decrement. Basically I want to know if there is a problem in those other drivers that is being protected against here! > > Yours, > Linus Walleij
Re: [PATCH v10 1/3] PCI: portdrv: Add pcie_port_service_get_irq() function
On Sat, 10 Apr 2021 01:22:16 +0900
Kunihiko Hayashi wrote:
> Add pcie_port_service_get_irq() that returns the virtual IRQ number
> for specified portdrv service.
Trivial comment inline.
>
> Cc: Lorenzo Pieralisi
> Signed-off-by: Kunihiko Hayashi
> Reviewed-by: Rob Herring
> Acked-by: Bjorn Helgaas
> ---
> drivers/pci/pcie/portdrv.h | 1 +
> drivers/pci/pcie/portdrv_core.c | 16
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
> index 2ff5724..628a3de 100644
> --- a/drivers/pci/pcie/portdrv.h
> +++ b/drivers/pci/pcie/portdrv.h
> @@ -144,4 +144,5 @@ static inline void pcie_pme_interrupt_enable(struct
> pci_dev *dev, bool en) {}
> #endif /* !CONFIG_PCIE_PME */
>
> struct device *pcie_port_find_device(struct pci_dev *dev, u32 service);
> +int pcie_port_service_get_irq(struct pci_dev *dev, u32 service);
> #endif /* _PORTDRV_H_ */
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index e1fed664..b60f0f3 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -477,7 +477,22 @@ struct device *pcie_port_find_device(struct pci_dev *dev,
> }
> EXPORT_SYMBOL_GPL(pcie_port_find_device);
>
> +/*
/**
this is kernel-doc style, so why not mark it as such?
> + * pcie_port_service_get_irq - get irq of the service
> + * @dev: PCI Express port the service is associated with
> + * @service: For the service to find
> + *
> + * Get IRQ number associated with given service on a pci_dev.
> + */
> +int pcie_port_service_get_irq(struct pci_dev *dev, u32 service)
> +{
> + struct pcie_device *pciedev;
> +
> + pciedev = to_pcie_device(pcie_port_find_device(dev, service));
> +
> + return pciedev->irq;
> +}
> +
> /**
> * pcie_port_device_remove - unregister PCI Express port service devices
> * @dev: PCI Express port the service devices to unregister are associated
> with
Re: [PATCH] iio: proximity: pulsedlight: Fix rumtime PM imbalance on error
On Wed, 7 Apr 2021 12:59:35 +0800
Dinghao Liu wrote:
> When lidar_write_control() fails, a pairing PM usage counter
> decrement is needed to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu
Hi, patch content looks good but it needs a fixes tag so we know how far to
backport it.
Please add for v2.
Thanks,
Jonathan
> ---
> drivers/iio/proximity/pulsedlight-lidar-lite-v2.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> index c685f10b5ae4..cc206bfa09c7 100644
> --- a/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> +++ b/drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
> @@ -160,6 +160,7 @@ static int lidar_get_measurement(struct lidar_data *data,
> u16 *reg)
> ret = lidar_write_control(data, LIDAR_REG_CONTROL_ACQUIRE);
> if (ret < 0) {
> dev_err(>dev, "cannot send start measurement command");
> + pm_runtime_put_noidle(>dev);
> return ret;
> }
>
Re: [PATCH] iio: light: gp2ap002: Fix rumtime PM imbalance on error
On Wed, 7 Apr 2021 11:49:27 +0800
Dinghao Liu wrote:
> When devm_request_threaded_irq() fails, we should decrease the
> runtime PM counter to keep the counter balanced. But when
> iio_device_register() fails, we need not to decrease it because
> we have already decreased it before.
Whilst agree with your assessment that the code is wrong, I'm not
totally sure why we need to do the pm_runtime_get_noresume() in
the first place. Why do we need to hold the reference for
the operations going on here? What can race against this that
might care about that reference count?
Jonathan
>
> Signed-off-by: Dinghao Liu
> ---
> drivers/iio/light/gp2ap002.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/light/gp2ap002.c b/drivers/iio/light/gp2ap002.c
> index 7ba7aa59437c..040d8429a6e0 100644
> --- a/drivers/iio/light/gp2ap002.c
> +++ b/drivers/iio/light/gp2ap002.c
> @@ -583,7 +583,7 @@ static int gp2ap002_probe(struct i2c_client *client,
> "gp2ap002", indio_dev);
> if (ret) {
> dev_err(dev, "unable to request IRQ\n");
> - goto out_disable_vio;
> + goto out_put_pm;
> }
> gp2ap002->irq = client->irq;
>
> @@ -613,8 +613,9 @@ static int gp2ap002_probe(struct i2c_client *client,
>
> return 0;
>
> -out_disable_pm:
> +out_put_pm:
> pm_runtime_put_noidle(dev);
> +out_disable_pm:
> pm_runtime_disable(dev);
> out_disable_vio:
> regulator_disable(gp2ap002->vio);
Re: [PATCH v4 2/2] iio: temperature: add driver support for ti tmp117
On Wed, 7 Apr 2021 23:51:47 +0530
Puranjay Mohan wrote:
> TMP117 is a Digital temperature sensor with integrated Non-Volatile memory.
> Add support for tmp117 driver in iio subsystem.
>
> Datasheet: https://www.ti.com/lit/gpn/tmp117
> Signed-off-by: Puranjay Mohan
> Reviewed-by: Andy Shevchenko
A few really small things in here that I tidied up whilst applying and
running local build tests.
Note that as IIO is effectively closed for the coming merge window,
I'm queuing this up for the next cycle and it will be in linux-next
after the merge window closes in about 3 weeks time.
Thanks,
Jonathan
> +static int tmp117_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *channel, int *val,
> + int *val2, long mask)
> +{
> + struct tmp117_data *data = iio_priv(indio_dev);
> + s32 ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = i2c_smbus_read_word_swapped(data->client,
> + TMP117_REG_TEMP);
> + if (ret < 0)
> + return ret;
> + *val = sign_extend32(ret, 15);
> + return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_CALIBBIAS:
> + ret = i2c_smbus_read_word_swapped(data->client,
> + TMP117_REG_TEMP_OFFSET);
> + if (ret < 0)
> + return ret;
> + *val = sign_extend32(ret, 15);
> + return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_SCALE:
> + /* Conversion from 10s of uC to mC
Totally trivial so I'll fix it whilst applying, but comment convention used
in IIO is
/*
* Conversion
> + * as IIO reports temperature in mC
> + */
> + *val = TMP117_RESOLUTION_10UC / MICRODEGREE_PER_10MILLIDEGREE;
> + *val2 = (TMP117_RESOLUTION_10UC %
> + MICRODEGREE_PER_10MILLIDEGREE) * 100;
> +
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int tmp117_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *channel, int val,
> + int val2, long mask)
> +{
> + struct tmp117_data *data = iio_priv(indio_dev);
> + s16 off;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_CALIBBIAS:
> + off = clamp(val, S16_MIN, S16_MAX);
With a C=1 W=1 build (sparse an lots of warnings) this causes problems because
the S16_MIN and S16_MAX are as you might imagine s16 values whereas val is
an int. I've added casts to force S16_MIN and S16_MAX to ints as well.
> + if (off == data->calibbias)
> + return 0;
> + data->calibbias = off;
> + return i2c_smbus_write_word_swapped(data->client,
> + TMP117_REG_TEMP_OFFSET, off);
> +
> + default:
> + return -EINVAL;
> + }
> +}
...
Re: [PATCH] iio: adc: exynos: drop unneeded variable assignment
On Sat, 10 Apr 2021 18:47:28 +0200 Krzysztof Kozlowski wrote: > The initialization of 'ret' variable in probe function is shortly after > overwritten. This initialization is simply not used. > > Addresses-Coverity: Unused value > Signed-off-by: Krzysztof Kozlowski Too late for this cycle, but I've queued it up for the next one. Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to see if we missed anything. Thanks, Jonathan > --- > drivers/iio/adc/exynos_adc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c > index 784c10deeb1a..2d8e36408f0e 100644 > --- a/drivers/iio/adc/exynos_adc.c > +++ b/drivers/iio/adc/exynos_adc.c > @@ -794,7 +794,7 @@ static int exynos_adc_probe(struct platform_device *pdev) > struct s3c2410_ts_mach_info *pdata = dev_get_platdata(>dev); > struct iio_dev *indio_dev = NULL; > bool has_ts = false; > - int ret = -ENODEV; > + int ret; > int irq; > > indio_dev = devm_iio_device_alloc(>dev, sizeof(struct > exynos_adc));
Re: [PATCH] HID: hid-sensor-custom: remove useless variable
On Fri, 09 Apr 2021 11:19:12 -0700
Srinivas Pandruvada wrote:
> On Fri, 2021-04-09 at 15:15 +0800, Jiapeng Chong wrote:
> > Fix the following gcc warning:
> >
> > drivers/hid/hid-sensor-custom.c:400:7: warning: variable ‘ret’ set
> > but
> > not used [-Wunused-but-set-variable].
> >
> > Reported-by: Abaci Robot
> > Signed-off-by: Jiapeng Chong
> Acked-by: Srinivas Pandruvada
> > ---
> > drivers/hid/hid-sensor-custom.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-
> > sensor-custom.c
> > index 2628bc5..e430673 100644
> > --- a/drivers/hid/hid-sensor-custom.c
> > +++ b/drivers/hid/hid-sensor-custom.c
> > @@ -397,15 +397,14 @@ static ssize_t store_value(struct device *dev,
> > struct device_attribute *attr,
> >
> > if (!strncmp(name, "value", strlen("value"))) {
> > u32 report_id;
> > - int ret;
> >
> > if (kstrtoint(buf, 0, ) != 0)
> > return -EINVAL;
> >
> > report_id = sensor_inst->fields[field_index].attribute.
> > report_
> > id;
> > - ret = sensor_hub_set_feature(sensor_inst->hsdev,
> > report_id,
> > -index, sizeof(value),
> > );
> > + sensor_hub_set_feature(sensor_inst->hsdev, report_id,
> > index,
> > + sizeof(value), );
> > } else
> > return -EINVAL;
> >
>
Re: [PATCH 2/3] staging: iio: cdc: ad7746: use dt bindings to set the EXCx pins output
On Sat, 10 Apr 2021 19:15:39 +0300
Alexandru Ardelean wrote:
> On Sat, Apr 10, 2021 at 7:12 PM Alexandru Ardelean
> wrote:
> >
> > On Fri, Apr 9, 2021 at 9:51 PM Lucas Stankus
> > wrote:
> > >
> > > Ditch platform_data fields in favor of device tree properties for
> > > configuring EXCA and EXCB output.
> > > This also removes the fields from the platform_data struct, since they're
> > > not used anymore.
> > >
> > > Signed-off-by: Lucas Stankus
> > > ---
> > > drivers/staging/iio/cdc/ad7746.c | 33 +---
> > > drivers/staging/iio/cdc/ad7746.h | 4
> > > 2 files changed, 18 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/cdc/ad7746.c
> > > b/drivers/staging/iio/cdc/ad7746.c
> > > index dfd71e99e872..63041b164dbe 100644
> > > --- a/drivers/staging/iio/cdc/ad7746.c
> > > +++ b/drivers/staging/iio/cdc/ad7746.c
> > > @@ -677,8 +677,10 @@ static int ad7746_probe(struct i2c_client *client,
> > > const struct i2c_device_id *id)
> > > {
> > > struct ad7746_platform_data *pdata = client->dev.platform_data;
> > > + struct device_node *np = client->dev.of_node;
> > > struct ad7746_chip_info *chip;
> > > struct iio_dev *indio_dev;
> > > + unsigned int exca_en, excb_en;
> > > unsigned char regval = 0;
> > > int ret = 0;
> > >
> > > @@ -703,26 +705,27 @@ static int ad7746_probe(struct i2c_client *client,
> > > indio_dev->num_channels = ARRAY_SIZE(ad7746_channels);
> > > indio_dev->modes = INDIO_DIRECT_MODE;
> > >
> >
> > [1]
> >
> > > - if (pdata) {
> > > - if (pdata->exca_en) {
> > > - if (pdata->exca_inv_en)
> > > - regval |= AD7746_EXCSETUP_NEXCA;
> > > - else
> > > - regval |= AD7746_EXCSETUP_EXCA;
> > > - }
> > > + ret = of_property_read_u32(np, "adi,exca-output", _en);
> >
> > maybe a better idea would be to use:
> >
> > device_property_read_u32(dev, )
> > where:
> > dev = client->dev.;
> >
> > this would make the driver a bit more friendly with both OF and ACPI
> >
> > > + if (!ret && exca_en) {
> > > + if (exca_en == 1)
> > > + regval |= AD7746_EXCSETUP_EXCA;
> > > + else
> > > + regval |= AD7746_EXCSETUP_NEXCA;
> > > + }
> > >
> > > - if (pdata->excb_en) {
> > > - if (pdata->excb_inv_en)
> > > - regval |= AD7746_EXCSETUP_NEXCB;
> > > - else
> > > - regval |= AD7746_EXCSETUP_EXCB;
> > > - }
> > > + ret = of_property_read_u32(np, "adi,excb-output", _en);
> > > + if (!ret && excb_en) {
> > > + if (excb_en == 1)
> > > + regval |= AD7746_EXCSETUP_EXCB;
> > > + else
> > > + regval |= AD7746_EXCSETUP_NEXCB;
> > > + }
> > >
> > > + if (pdata) {
> > > regval |= AD7746_EXCSETUP_EXCLVL(pdata->exclvl);
> > > } else {
> > > dev_warn(>dev, "No platform data? using
> > > default\n");
> > > - regval = AD7746_EXCSETUP_EXCA | AD7746_EXCSETUP_EXCB |
> > > - AD7746_EXCSETUP_EXCLVL(3);
> >
> > This logic is problematic now.
> > Because no matter what you're setting in the DT, it always gets
> > overridden here because there is no platform data.
> >
> > Maybe a better idea is to do something like:
> > if (!pdata)
> > regval = AD7746_EXCSETUP_EXCLVL(3);
> >
> > but this should be placed somewhere around [1]
>
> [ i can see that this logic will get corrected in the next patch]
> to add here a bit: the idea of a patch is that it should try to not
> introduce any [even temporary] breakage, even when it's in a series;
> if a driver was already broken, then it should get fixed via it's own patch;
> but no patch should introduce any breakages [if possible]
The two patches are small enough I'd be fine with them being merged into one
that avoiding any special handling. Just add a note to the patch description
to say that it was done in one patch for this reason.
Jonathan
>
> >
> >
> > > + regval = AD7746_EXCSETUP_EXCLVL(3);
> > > }
> > >
> > > ret = i2c_smbus_write_byte_data(chip->client,
> > > diff --git a/drivers/staging/iio/cdc/ad7746.h
> > > b/drivers/staging/iio/cdc/ad7746.h
> > > index 8bdbd732dbbd..6cae4ecf779e 100644
> > > --- a/drivers/staging/iio/cdc/ad7746.h
> > > +++ b/drivers/staging/iio/cdc/ad7746.h
> > > @@ -19,10 +19,6 @@
> > >
> > > struct ad7746_platform_data {
> > > unsigned char exclvl; /*Excitation Voltage Level */
> > > - bool exca_en; /* enables EXCA pin as the excitation
> > > output */
> > > - bool exca_inv_en; /* enables /EXCA pin
Re: [PATCH 2/3] staging: iio: cdc: ad7746: use dt bindings to set the EXCx pins output
On Sat, 10 Apr 2021 13:05:14 +0300
Andy Shevchenko wrote:
> On Saturday, April 10, 2021, Andy Shevchenko
> wrote:
>
> >
> >
> > On Friday, April 9, 2021, Lucas Stankus wrote:
> >
> >> Ditch platform_data fields in favor of device tree properties for
> >> configuring EXCA and EXCB output.
> >> This also removes the fields from the platform_data struct, since they're
> >> not used anymore.
> >
> >
> > As far as I read the old code it’s possible to leave pins untouched, not
> > anymore the case after this patch. What datasheet tells about it? Please
> > elaborate in the commit message and add a Datasheet: tag as a reference.
> >
> >
> >
Default is to have them disabled, so if you switch to separate -en
vs -invert lack of either will correspond to the power on default
and simplify things somewhat.
>
> Okay, I see now. But can you simple use switch case or so, because
> currently code is not so understandable from the first glance?
>
>
>
> >
> >> Signed-off-by: Lucas Stankus
> >> ---
> >> drivers/staging/iio/cdc/ad7746.c | 33 +---
> >> drivers/staging/iio/cdc/ad7746.h | 4
> >> 2 files changed, 18 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/drivers/staging/iio/cdc/ad7746.c
> >> b/drivers/staging/iio/cdc/ad7746.c
> >> index dfd71e99e872..63041b164dbe 100644
> >> --- a/drivers/staging/iio/cdc/ad7746.c
> >> +++ b/drivers/staging/iio/cdc/ad7746.c
> >> @@ -677,8 +677,10 @@ static int ad7746_probe(struct i2c_client *client,
> >> const struct i2c_device_id *id)
> >> {
> >> struct ad7746_platform_data *pdata = client->dev.platform_data;
> >> + struct device_node *np = client->dev.of_node;
> >> struct ad7746_chip_info *chip;
> >> struct iio_dev *indio_dev;
> >> + unsigned int exca_en, excb_en;
> >> unsigned char regval = 0;
> >> int ret = 0;
> >>
> >> @@ -703,26 +705,27 @@ static int ad7746_probe(struct i2c_client *client,
> >> indio_dev->num_channels = ARRAY_SIZE(ad7746_channels);
> >> indio_dev->modes = INDIO_DIRECT_MODE;
> >>
> >> - if (pdata) {
> >> - if (pdata->exca_en) {
> >> - if (pdata->exca_inv_en)
> >> - regval |= AD7746_EXCSETUP_NEXCA;
> >> - else
> >> - regval |= AD7746_EXCSETUP_EXCA;
> >> - }
> >> + ret = of_property_read_u32(np, "adi,exca-output", _en);
> >> + if (!ret && exca_en) {
> >> + if (exca_en == 1)
> >> + regval |= AD7746_EXCSETUP_EXCA;
> >> + else
> >> + regval |= AD7746_EXCSETUP_NEXCA;
> >> + }
> >>
> >> - if (pdata->excb_en) {
> >> - if (pdata->excb_inv_en)
> >> - regval |= AD7746_EXCSETUP_NEXCB;
> >> - else
> >> - regval |= AD7746_EXCSETUP_EXCB;
> >> - }
> >> + ret = of_property_read_u32(np, "adi,excb-output", _en);
> >> + if (!ret && excb_en) {
> >> + if (excb_en == 1)
> >> + regval |= AD7746_EXCSETUP_EXCB;
> >> + else
> >> + regval |= AD7746_EXCSETUP_NEXCB;
> >> + }
> >>
> >> + if (pdata) {
> >> regval |= AD7746_EXCSETUP_EXCLVL(pdata->exclvl);
> >> } else {
> >> dev_warn(>dev, "No platform data? using
> >> default\n");
> >> - regval = AD7746_EXCSETUP_EXCA | AD7746_EXCSETUP_EXCB |
> >> - AD7746_EXCSETUP_EXCLVL(3);
> >> + regval = AD7746_EXCSETUP_EXCLVL(3);
> >> }
> >>
> >> ret = i2c_smbus_write_byte_data(chip->client,
> >> diff --git a/drivers/staging/iio/cdc/ad7746.h
> >> b/drivers/staging/iio/cdc/ad7746.h
> >> index 8bdbd732dbbd..6cae4ecf779e 100644
> >> --- a/drivers/staging/iio/cdc/ad7746.h
> >> +++ b/drivers/staging/iio/cdc/ad7746.h
> >> @@ -19,10 +19,6 @@
> >>
> >> struct ad7746_platform_data {
> >> unsigned char exclvl; /*Excitation Voltage Level */
> >> - bool exca_en; /* enables EXCA pin as the excitation
> >> output */
> >> - bool exca_inv_en; /* enables /EXCA pin as the excitation
> >> output */
> >> - bool excb_en; /* enables EXCB pin as the excitation
> >> output */
> >> - bool excb_inv_en; /* enables /EXCB pin as the excitation
> >> output */
> >> };
> >>
> >> #endif /* IIO_CDC_AD7746_H_ */
> >> --
> >> 2.31.1
> >>
> >>
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
> >
>
Re: [PATCH 1/3] dt-bindings: staging: iio: cdc: ad7746: add binding documentation for AD7746
On Fri, 9 Apr 2021 15:50:10 -0300
Lucas Stankus wrote:
> Add device tree binding documentation for AD7746 cdc in YAML format.
>
> Signed-off-by: Lucas Stankus
Hi Lucas,
Good to see progress on this one after all these years :)
I think we can do a bit better though by making the attributes
easy to comprehend without needing to refer to the documentation.
Always good to avoid magic numbers if we can.
Suggestions inline.
Jonathan
> ---
> .../bindings/iio/cdc/adi,ad7746.yaml | 79 +++
> 1 file changed, 79 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml
> b/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml
> new file mode 100644
> index ..5de86f4374e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/cdc/adi,ad7746.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AD7746 24-Bit Capacitance-to-Digital Converter with Temperature Sensor
> +
> +maintainers:
> + - Michael Hennerich
> +
> +description: |
> + AD7746 24-Bit Capacitance-to-Digital Converter with Temperature Sensor
> +
> + Specifications about the part can be found at:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7291.pdf
> +
> +properties:
> + compatible:
> +enum:
> + - adi,ad7745
> + - adi,ad7746
> + - adi,ad7747
> +
> + reg:
> +description: |
> + Physiscal address of the EXC set-up register.
reg in this case would be the i2c address.
> +maxItems: 1
> +
> + adi,excitation-voltage-level:
This isn't a level as such, it's a scale factor, or something like
that and the naming should reflect that + the values
should be real in some sense (multipliers so
perhaps something like adi,excitation-vdd-milicent ?
schema/property-units.yaml includes -percent but that doesn't
have enough precision.
enum [125, 250, 375, 500]
> +description: |
> + Select the reference excitation voltage level used by the device.
> + With VDD being the power supply voltage, valid values are:
> + 0: +-VDD / 8
> + 1: +-VDD / 4
> + 2: +-VDD * 3 / 8
> + 3: +-VDD / 2
> + If left empty option 3 is selected.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [0, 1, 2, 3]
> +
> + adi,exca-output:
> +description: |
> + Sets the excitation output in the exca pin.
> + Valid values are:
> + 0: Disables output in the EXCA pin.
> + 1: Enables EXCA pin as the excitation output.
> + 2: Enables EXCA pin as the inverted excitation output.
Hmm. Various ways we could do this and avoid the need for
a enum representing several different things. Perhaps
adi,exa-output-en
adi,exa-output-invert
(appropriate checks so we can only have invert of the channel
is enabled as otherwise it is less than meaningful)
> + If left empty the output is disabled.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [0, 1, 2]
> +
> + adi,excb-output:
> +description: |
> + Analoguos to the adi,exca-output for the EXCB pin.
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [0, 1, 2]
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ad7746: cdc@0 {
> +compatible = "adi,ad7746";
> +reg = <0>;
That's very unlikely as an i2c address.
> +adi,excitation-voltage-level = <3>;
> +adi,exca-output = <0>;
> +adi,excb-output = <0>;
> + };
> +};
> +...
Re: [RFC PATCH 01/10] genirq: Add chip flag to denote automatic IRQ (un)masking
On Thu, 8 Apr 2021 16:43:17 +0100
Valentin Schneider wrote:
> Some IRQ chips such as the Arm GICs automagically mask / unmask an
> IRQ during the handling of said IRQ. This renders further mask / unmask
> operations within the flow handlers redundant, which we do want to leverage
> as masking by itself is not cheap (Distributor access via MMIO for GICs).
>
> This is different from having a chip->irq_mask_ack() callback as this
> masking is:
> - inherent to the chip->irq_ack() and *cannot* be omitted
> - a *different* masking state than chip->irq_mask() (chip->irq_mask() is
> idempotent, chip->irq_ack() really isn't)
>
> Add a chip flag, IRQCHIP_AUTOMASKS_FLOW, to denote chips with such
> behaviour. Add a new IRQ data flag, IRQD_IRQ_FLOW_MASKED, to keep this
> flow-induced mask state separate from regular mask / unmask operations
> (IRQD_IRQ_MASKED).
>
> Signed-off-by: Valentin Schneider
Hi Valentin,
One totally trivial thing noticed whilst reading.
> ---
> include/linux/irq.h| 10 ++
> kernel/irq/chip.c | 5 +
> kernel/irq/debugfs.c | 2 ++
> kernel/irq/internals.h | 5 +
> 4 files changed, 22 insertions(+)
>
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index bee82809107c..580b1b6b1799 100644
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -219,6 +219,8 @@ struct irq_data {
> * irq_chip::irq_set_affinity() when deactivated.
> * IRQD_IRQ_ENABLED_ON_SUSPEND - Interrupt is enabled on suspend by
> irq pm if
> * irqchip have flag
> IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND set.
> + * IRQD_IRQ_FLOW_MASKED - Interrupt is masked by ACK. Only EOI can
> + *clear this.
Nitpick of the day : Seems text above is using tabs for white space blocks
whereas you have used spaces. Make it consistent.
It's not consistent in the file so I guess you could clean that up, or
just go with making it consistent in this block.
> */
> enum {
> IRQD_TRIGGER_MASK = 0xf,
> @@ -245,6 +247,7 @@ enum {
> IRQD_HANDLE_ENFORCE_IRQCTX = (1 << 28),
> IRQD_AFFINITY_ON_ACTIVATE = (1 << 29),
> IRQD_IRQ_ENABLED_ON_SUSPEND = (1 << 30),
> + IRQD_IRQ_FLOW_MASKED= (1 << 31),
> };
>
> #define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
> @@ -349,6 +352,11 @@ static inline bool irqd_irq_masked(struct irq_data *d)
> return __irqd_to_state(d) & IRQD_IRQ_MASKED;
> }
>
> +static inline bool irqd_irq_flow_masked(struct irq_data *d)
> +{
> + return __irqd_to_state(d) & IRQD_IRQ_FLOW_MASKED;
> +}
> +
> static inline bool irqd_irq_inprogress(struct irq_data *d)
> {
> return __irqd_to_state(d) & IRQD_IRQ_INPROGRESS;
> @@ -567,6 +575,7 @@ struct irq_chip {
> * IRQCHIP_SUPPORTS_NMI: Chip can deliver NMIs, only for root
> irqchips
> * IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND: Invokes __enable_irq()/__disable_irq()
> for wake irqs
> *in the suspend path if they are in
> disabled state
> + * IRQCHIP_AUTOMASKS_FLOW:chip->ack() masks and chip->eoi()
> unmasks
> */
> enum {
> IRQCHIP_SET_TYPE_MASKED = (1 << 0),
> @@ -579,6 +588,7 @@ enum {
> IRQCHIP_SUPPORTS_LEVEL_MSI = (1 << 7),
> IRQCHIP_SUPPORTS_NMI= (1 << 8),
> IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND= (1 << 9),
> + IRQCHIP_AUTOMASKS_FLOW = (1 << 10),
> };
>
> #include
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 8cc8e5713287..18c3b0e1568a 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -173,6 +173,11 @@ static void irq_state_clr_masked(struct irq_desc *desc)
> irqd_clear(>irq_data, IRQD_IRQ_MASKED);
> }
>
> +static void irq_state_clr_flow_masked(struct irq_desc *desc)
> +{
> + irqd_clear(>irq_data, IRQD_IRQ_FLOW_MASKED);
> +}
> +
> static void irq_state_clr_started(struct irq_desc *desc)
> {
> irqd_clear(>irq_data, IRQD_IRQ_STARTED);
> diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
> index e4cff358b437..3ae83622d701 100644
> --- a/kernel/irq/debugfs.c
> +++ b/kernel/irq/debugfs.c
> @@ -58,6 +58,7 @@ static const struct irq_bit_descr irqchip_flags[] = {
> BIT_MASK_DESCR(IRQCHIP_SUPPORTS_LEVEL_MSI),
> BIT_MASK_DESCR(IRQCHIP_SUPPORTS_NMI),
> BIT_MASK_DESCR(IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND),
> + BIT_MASK_DESCR(IRQCHIP_AUTOMASKS_FLOW),
> };
>
> static void
> @@ -103,6 +104,7 @@ static const struct irq_bit_descr irqdata_states[] = {
> BIT_MASK_DESCR(IRQD_IRQ_STARTED),
> BIT_MASK_DESCR(IRQD_IRQ_DISABLED),
> BIT_MASK_DESCR(IRQD_IRQ_MASKED),
> + BIT_MASK_DESCR(IRQD_IRQ_FLOW_MASKED),
> BIT_MASK_DESCR(IRQD_IRQ_INPROGRESS),
>
> BIT_MASK_DESCR(IRQD_PER_CPU),
> diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
> index
Re: [PATCH 7/7] cxl: Add HDM decoder capbilities
On Wed, 7 Apr 2021 15:26:25 -0700
Ben Widawsky wrote:
> An HDM decoder is defined in the CXL 2.0 specification as a mechanism
> that allow devices and upstream ports to claim memory address ranges and
> participate in interleave sets. HDM decoder registers are within the
> component register block defined in CXL 2.0 8.2.3 CXL 2.0 Component
> Registers as part of the CXL.cache and CXL.mem subregion.
>
> The Component Register Block is found via the Register Locator DVSEC
> in a similar fashion to how the CXL Device Register Block is found. The
> primary difference is the capability id size of the Component Register
> Block is a single DWORD instead of 4 DWORDS.
>
> It's now possible to configure a CXL type 3 device's HDM decoder. Such
> programming is expected for CXL devices with persistent memory, and hot
> plugged CXL devices that participate in CXL.mem with volatile memory.
>
> Signed-off-by: Ben Widawsky
Some register field naming suggestions. Otherwise looks fine to me.
> ---
> drivers/cxl/core.c | 73 ++
> drivers/cxl/cxl.h | 48 ++
> drivers/cxl/mem.c | 37 ---
> drivers/cxl/pci.h | 1 +
> 4 files changed, 155 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cxl/core.c b/drivers/cxl/core.c
> index 65cd704581bc..db6a83eed0a2 100644
> --- a/drivers/cxl/core.c
> +++ b/drivers/cxl/core.c
> @@ -479,6 +479,79 @@ struct cxl_port *devm_cxl_add_port(struct device *host,
> }
> EXPORT_SYMBOL_GPL(devm_cxl_add_port);
>
> +void cxl_setup_component_regs(struct device *dev, void __iomem *base,
> + struct cxl_component_regs *regs)
> +{
> + int cap, cap_count;
> + u64 cap_array;
> +
> + *regs = (struct cxl_component_regs) { 0 };
> +
> + /*
> + * CXL.cache and CXL.mem registers are at offset 0x1000 as defined in
> + * CXL 2.0 8.2.4 Table 141.
> + *
> + * TODO: Map other registers as needed.
> + */
> + base += CXL_CM_OFFSET;
> +
> + cap_array = readq(base + CXL_CM_CAP_HDR_OFFSET);
> +
> + if (FIELD_GET(CXL_CM_CAP_HDR_ID_MASK, cap_array) != CM_CAP_HDR_CAP_ID) {
> + dev_err(dev,
> + "Couldn't locate the CXL.cache and CXL.mem capability
> array header./n");
> + return;
> + }
> +
> + /* It's assumed that future versions will be backward compatible */
> +#define CAPID_VERSION_CHECK(data, mask, expected, capability_msg)
> \
> + do { \
> + if (FIELD_GET(mask, data) < expected) {\
> + dev_err(dev, \
> + capability_msg \
> + " version %ld is below expected %d", \
/n
> + FIELD_GET(mask, data), expected); \
> + return;\
> + } \
> + } while (0)
> +
> + CAPID_VERSION_CHECK(cap_array, CXL_CM_CAP_HDR_VERSION_MASK,
> + CM_CAP_HDR_CAP_VERSION, "Capability array header");
> + CAPID_VERSION_CHECK(cap_array, CXL_CM_CAP_HDR_CACHE_MEM_VERSION_MASK,
> + CM_CAP_HDR_CACHE_MEM_VERSION,
> + "Capability array header CXL.cache CXL.mem");
Is that macro worth bothering with? Particularly as it will make the string
harder to grep for.
ver = FIELD_GET(CXL_CM_CAP_HDR_VERSION_MASK, cap_array);
if (ver < CM_CAP_HDR_CAP_VERSION)) {
dev_err(dev, "Capability array header version %ld is below
expected %d./n",
ver, CM_CAP_HDER_CAP_VERSION);
etc seems better to me given we only have two instances.
> +
> + cap_count = FIELD_GET(CXL_CM_CAP_HDR_ARRAY_SIZE_MASK, cap_array);
> +
> + for (cap = 1; cap <= cap_count; cap++) {
> + void __iomem *register_block;
> + u32 hdr;
> + u16 cap_id, offset;
> +
> + hdr = readl(base + cap * 0x4);
> +
> + cap_id = FIELD_GET(CXL_CM_CAP_HDR_ID_MASK, hdr);
See below, but I'd suggest some name changes for defines. Whilst
it's the same value, this is in a different type of entry to where
you use CXL_CM_CAP_HDR_ID_MASK above. Confused me so may confuse
others :)
> + offset = FIELD_GET(CXL_CM_CAP_PTR_MASK, hdr);
> + register_block = base + offset;
> +
> + switch (cap_id) {
> + case CXL_CM_CAP_CAP_ID_HDM:
> + CAPID_VERSION_CHECK(hdr, CXL_CM_CAP_HDR_VERSION_MASK,
> + CXL_CM_CAP_CAP_HDM_VERSION,
> + "HDM decoder capability");
> + dev_dbg(dev, "found HDM decoder
Re: [PATCH 6/7] cxl/mem: Create a helper to setup device regs
On Wed, 7 Apr 2021 15:26:24 -0700
Ben Widawsky wrote:
> Memory devices have a list of required register regions within the
> register block, but this isn't required of all CXL components or
> devices. To make things more tidy, and allow for easily setting up other
> block types in this loop, the helper is introduced.
Two things in here, the move and allowing it to be missing.
I would call that out explicitly in the patch description.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/cxl/mem.c | 38 +++---
> 1 file changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 49f651694cb0..b7342aaf38c4 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -974,6 +974,24 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> return 0;
> }
>
> +static int __cxl_setup_device_regs(struct cxl_mem *cxlm, void __iomem *base)
Naming is a little unusual. Normally __ would imply unlocked or something
like that, whereas here it's mostly implying more error checks.
I don't immediately have a good idea for a name however...
> +{
> + struct cxl_regs *regs = >regs;
> + struct pci_dev *pdev = cxlm->pdev;
> + struct device *dev = >dev;
> +
> + cxl_setup_device_regs(dev, base, >device_regs);
> + if (!regs->status || !regs->mbox || !regs->memdev) {
> + dev_err(dev, "registers not found: %s%s%s\n",
> + !regs->status ? "status " : "",
> + !regs->mbox ? "mbox " : "",
> + !regs->memdev ? "memdev" : "");
> + return -ENXIO;
> + }
> +
> + return 0;
> +}
> +
> /**
> * cxl_mem_setup_regs() - Setup necessary MMIO.
> * @cxlm: The CXL memory device to communicate with.
> @@ -986,12 +1004,11 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int
> dvsec)
> */
> static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> {
> - struct cxl_regs *regs = >regs;
> struct pci_dev *pdev = cxlm->pdev;
> struct device *dev = >dev;
> u32 regloc_size, regblocks;
> void __iomem *base;
> - int regloc, i;
> + int regloc, i, rc;
>
> regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC_OFFSET);
> if (!regloc) {
> @@ -1021,23 +1038,14 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> if (IS_ERR(base))
> return PTR_ERR(base);
>
> - cxl_setup_device_regs(dev, base, >device_regs);
> - if (!regs->status || !regs->mbox || !regs->memdev) {
> - dev_err(dev, "registers not found: %s%s%s\n",
> - !regs->status ? "status " : "",
> - !regs->mbox ? "mbox " : "",
> - !regs->memdev ? "memdev" : "");
> - return -ENXIO;
> - }
> + rc = __cxl_setup_device_regs(cxlm, base);
> + if (rc)
> + return rc;
> +
> break;
> }
> }
>
> - if (i == regblocks) {
> - dev_err(dev, "Missing register locator for device registers\n");
> - return -ENXIO;
> - }
> -
> return 0;
> }
>
Re: [PATCH 5/7] cxl/mem: Move device register setup
On Wed, 7 Apr 2021 15:26:23 -0700
Ben Widawsky wrote:
> Support expansion of register block types that the driver will attempt
> to recognize by pulling the code up into the register block scanning
> loop. Subsequent code can easily add in new register block types with
> this.
>
> Signed-off-by: Ben Widawsky
Acked-by: Jonathan Cameron >
> ---
> drivers/cxl/mem.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 60b95c524c3e..49f651694cb0 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -1020,6 +1020,15 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> base = cxl_mem_map_regblock(cxlm, reg_lo, reg_hi);
> if (IS_ERR(base))
> return PTR_ERR(base);
> +
> + cxl_setup_device_regs(dev, base, >device_regs);
> + if (!regs->status || !regs->mbox || !regs->memdev) {
> + dev_err(dev, "registers not found: %s%s%s\n",
> + !regs->status ? "status " : "",
> + !regs->mbox ? "mbox " : "",
> + !regs->memdev ? "memdev" : "");
> + return -ENXIO;
> + }
> break;
> }
> }
> @@ -1029,16 +1038,6 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> return -ENXIO;
> }
>
> - cxl_setup_device_regs(dev, base, >device_regs);
> -
> - if (!regs->status || !regs->mbox || !regs->memdev) {
> - dev_err(dev, "registers not found: %s%s%s\n",
> - !regs->status ? "status " : "",
> - !regs->mbox ? "mbox " : "",
> - !regs->memdev ? "memdev" : "");
> - return -ENXIO;
> - }
> -
> return 0;
> }
>
Re: [PATCH 3/7] cxl/mem: Move register locator logic into reg setup
On Wed, 7 Apr 2021 15:26:21 -0700
Ben Widawsky wrote:
> Start moving code around to ultimately get rid of @cxlm.base. The
> @cxlm.base member serves no purpose other than intermediate storage of
> the offset found in cxl_mem_map_regblock() later used by
> cxl_mem_setup_regs(). Aside from wanting to get rid of this useless
> member, it will help later when adding new register block identifiers.
>
> While @cxlm.base still exists, it will become trivial to remove it in a
> future patch.
>
> No functional change is meant to be introduced in this patch.
>
> Signed-off-by: Ben Widawsky
Seems like a noop refactor to me as you say.
Reviewed-by: Jonathan Cameron
> ---
> drivers/cxl/mem.c | 135 +++---
> 1 file changed, 68 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 520edaf233d4..04b4f7445083 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -870,34 +870,6 @@ static int cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm,
> u16 opcode,
> return 0;
> }
>
> -/**
> - * cxl_mem_setup_regs() - Setup necessary MMIO.
> - * @cxlm: The CXL memory device to communicate with.
> - *
> - * Return: 0 if all necessary registers mapped.
> - *
> - * A memory device is required by spec to implement a certain set of MMIO
> - * regions. The purpose of this function is to enumerate and map those
> - * registers.
> - */
> -static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> -{
> - struct device *dev = >pdev->dev;
> - struct cxl_regs *regs = >regs;
> -
> - cxl_setup_device_regs(dev, cxlm->base, >device_regs);
> -
> - if (!regs->status || !regs->mbox || !regs->memdev) {
> - dev_err(dev, "registers not found: %s%s%s\n",
> - !regs->status ? "status " : "",
> - !regs->mbox ? "mbox " : "",
> - !regs->memdev ? "memdev" : "");
> - return -ENXIO;
> - }
> -
> - return 0;
> -}
> -
> static int cxl_mem_setup_mailbox(struct cxl_mem *cxlm)
> {
> const int cap = readl(cxlm->regs.mbox + CXLDEV_MBOX_CAPS_OFFSET);
> @@ -1005,6 +977,73 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int
> dvsec)
> return 0;
> }
>
> +/**
> + * cxl_mem_setup_regs() - Setup necessary MMIO.
> + * @cxlm: The CXL memory device to communicate with.
> + *
> + * Return: 0 if all necessary registers mapped.
> + *
> + * A memory device is required by spec to implement a certain set of MMIO
> + * regions. The purpose of this function is to enumerate and map those
> + * registers.
> + */
> +static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> +{
> + struct cxl_regs *regs = >regs;
> + struct pci_dev *pdev = cxlm->pdev;
> + struct device *dev = >dev;
> + u32 regloc_size, regblocks;
> + int rc, regloc, i;
> +
> + regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC_OFFSET);
> + if (!regloc) {
> + dev_err(dev, "register location dvsec not found\n");
> + return -ENXIO;
> + }
> +
> + /* Get the size of the Register Locator DVSEC */
> + pci_read_config_dword(pdev, regloc + PCI_DVSEC_HEADER1, _size);
> + regloc_size = FIELD_GET(PCI_DVSEC_HEADER1_LENGTH_MASK, regloc_size);
> +
> + regloc += PCI_DVSEC_ID_CXL_REGLOC_BLOCK1_OFFSET;
> + regblocks = (regloc_size - PCI_DVSEC_ID_CXL_REGLOC_BLOCK1_OFFSET) / 8;
> +
> + for (i = 0; i < regblocks; i++, regloc += 8) {
> + u32 reg_lo, reg_hi;
> + u8 reg_type;
> +
> + /* "register low and high" contain other bits */
> + pci_read_config_dword(pdev, regloc, _lo);
> + pci_read_config_dword(pdev, regloc + 4, _hi);
> +
> + reg_type = FIELD_GET(CXL_REGLOC_RBI_MASK, reg_lo);
> +
> + if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
> + rc = cxl_mem_map_regblock(cxlm, reg_lo, reg_hi);
> + if (rc)
> + return rc;
> + break;
> + }
> + }
> +
> + if (i == regblocks) {
> + dev_err(dev, "Missing register locator for device registers\n");
> + return -ENXIO;
> + }
> +
> + cxl_setup_device_regs(dev, cxlm->base, >device_regs);
> +
> + if (!regs->status || !regs->mbox || !regs->memdev) {
> + dev_err(dev, "registers not found: %s%s%s\n",
> + !regs->status ? "status " : &q
Re: [PATCH 2/7] cxl/mem: Split creation from mapping in probe
On Wed, 7 Apr 2021 15:26:20 -0700
Ben Widawsky wrote:
> Add a new function specifically for mapping the register blocks and
> offsets within. The new function can be used more generically for other
> register block identifiers.
>
> No functional change is meant to be introduced in this patch with the
> exception of a dev_err printed when the device register block isn't
> found.
>
> Signed-off-by: Ben Widawsky
Agreed, this seems to be a noop refactor to me.
Reviewed-by: Jonathan Cameron
> ---
> drivers/cxl/mem.c | 64 +--
> 1 file changed, 40 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 99534260034e..520edaf233d4 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -925,22 +925,40 @@ static int cxl_mem_setup_mailbox(struct cxl_mem *cxlm)
> return 0;
> }
>
> -static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo,
> - u32 reg_hi)
> +static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev)
> {
> struct device *dev = >dev;
> struct cxl_mem *cxlm;
> - void __iomem *regs;
> - u64 offset;
> - u8 bar;
> - int rc;
>
> cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> if (!cxlm) {
> dev_err(dev, "No memory available\n");
> - return NULL;
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + mutex_init(>mbox_mutex);
> + cxlm->pdev = pdev;
> + cxlm->enabled_cmds =
> + devm_kmalloc_array(dev, BITS_TO_LONGS(cxl_cmd_count),
> +sizeof(unsigned long),
> +GFP_KERNEL | __GFP_ZERO);
> + if (!cxlm->enabled_cmds) {
> + dev_err(dev, "No memory available for bitmap\n");
> + return ERR_PTR(-ENOMEM);
> }
>
> + return cxlm;
> +}
> +
> +static int cxl_mem_map_regblock(struct cxl_mem *cxlm, u32 reg_lo, u32 reg_hi)
> +{
> + struct pci_dev *pdev = cxlm->pdev;
> + struct device *dev = >dev;
> + void __iomem *regs;
> + u64 offset;
> + u8 bar;
> + int rc;
> +
> offset = ((u64)reg_hi << 32) | FIELD_GET(CXL_REGLOC_ADDR_MASK, reg_lo);
> bar = FIELD_GET(CXL_REGLOC_BIR_MASK, reg_lo);
>
> @@ -948,30 +966,20 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev
> *pdev, u32 reg_lo,
> if (pci_resource_len(pdev, bar) < offset) {
> dev_err(dev, "BAR%d: %pr: too small (offset: %#llx)\n", bar,
> >resource[bar], (unsigned long long)offset);
> - return NULL;
> + return -ENXIO;
> }
>
> rc = pcim_iomap_regions(pdev, BIT(bar), pci_name(pdev));
> if (rc) {
> dev_err(dev, "failed to map registers\n");
> - return NULL;
> + return rc;
> }
> regs = pcim_iomap_table(pdev)[bar];
>
> - mutex_init(>mbox_mutex);
> - cxlm->pdev = pdev;
> cxlm->base = regs + offset;
> - cxlm->enabled_cmds =
> - devm_kmalloc_array(dev, BITS_TO_LONGS(cxl_cmd_count),
> -sizeof(unsigned long),
> -GFP_KERNEL | __GFP_ZERO);
> - if (!cxlm->enabled_cmds) {
> - dev_err(dev, "No memory available for bitmap\n");
> - return NULL;
> - }
>
> dev_dbg(dev, "Mapped CXL Memory Device resource\n");
> - return cxlm;
> + return 0;
> }
>
> static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> @@ -1403,14 +1411,18 @@ static int cxl_mem_identify(struct cxl_mem *cxlm)
> static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id
> *id)
> {
> struct device *dev = >dev;
> - struct cxl_mem *cxlm = NULL;
> u32 regloc_size, regblocks;
> + struct cxl_mem *cxlm;
> int rc, regloc, i;
>
> rc = pcim_enable_device(pdev);
> if (rc)
> return rc;
>
> + cxlm = cxl_mem_create(pdev);
> + if (IS_ERR(cxlm))
> + return PTR_ERR(cxlm);
> +
> regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC_OFFSET);
> if (!regloc) {
> dev_err(dev, "register location dvsec not found\n");
> @@ -1435,13 +1447,17 @@ static int cxl_mem_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
> reg_type = FIELD_GET(CXL_REGLOC_RBI_MASK, reg_lo);
>
> if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
> -
Re: [PATCH 4/7] cxl/mem: Get rid of @cxlm.base
On Wed, 7 Apr 2021 15:26:22 -0700
Ben Widawsky wrote:
> @cxlm.base only existed to support holding the base found in the
> register block mapping code, and pass it along to the register setup
> code. Now that the register setup function has all logic around managing
> the registers, from DVSEC to iomapping up to populating our CXL specific
> information, it is easy to turn the @base values into local variables
> and remove them from our device driver state.
>
> Signed-off-by: Ben Widawsky
Patch is basically fine, but I do wonder if you could avoid the
nasty casting in and out of __iomem in the error paths.
It's a common enough idiom though so I'm not htat fussed.
Acked-by: Jonathan Cameron
> ---
> drivers/cxl/mem.c | 24 +++-
> drivers/cxl/mem.h | 2 --
> 2 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 04b4f7445083..60b95c524c3e 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -922,11 +922,10 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev
> *pdev)
> return cxlm;
> }
>
> -static int cxl_mem_map_regblock(struct cxl_mem *cxlm, u32 reg_lo, u32 reg_hi)
> +static void __iomem *cxl_mem_map_regblock(struct cxl_mem *cxlm, u32 reg_lo,
> u32 reg_hi)
> {
> struct pci_dev *pdev = cxlm->pdev;
> struct device *dev = >dev;
> - void __iomem *regs;
> u64 offset;
> u8 bar;
> int rc;
> @@ -938,20 +937,18 @@ static int cxl_mem_map_regblock(struct cxl_mem *cxlm,
> u32 reg_lo, u32 reg_hi)
> if (pci_resource_len(pdev, bar) < offset) {
> dev_err(dev, "BAR%d: %pr: too small (offset: %#llx)\n", bar,
> >resource[bar], (unsigned long long)offset);
> - return -ENXIO;
> + return (void __iomem *)ERR_PTR(-ENXIO);
> }
>
> rc = pcim_iomap_regions(pdev, BIT(bar), pci_name(pdev));
> if (rc) {
> dev_err(dev, "failed to map registers\n");
> - return rc;
> + return (void __iomem *)ERR_PTR(rc);
The casting is fairly horrible, perhaps just pass in
a void __iomem ** and pass base back through that?
> }
> - regs = pcim_iomap_table(pdev)[bar];
> -
> - cxlm->base = regs + offset;
>
> dev_dbg(dev, "Mapped CXL Memory Device resource\n");
> - return 0;
> +
> + return pcim_iomap_table(pdev)[bar] + offset;
> }
>
> static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> @@ -993,7 +990,8 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> struct pci_dev *pdev = cxlm->pdev;
> struct device *dev = >dev;
> u32 regloc_size, regblocks;
> - int rc, regloc, i;
> + void __iomem *base;
> + int regloc, i;
>
> regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC_OFFSET);
> if (!regloc) {
> @@ -1019,9 +1017,9 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> reg_type = FIELD_GET(CXL_REGLOC_RBI_MASK, reg_lo);
>
> if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
> - rc = cxl_mem_map_regblock(cxlm, reg_lo, reg_hi);
> - if (rc)
> - return rc;
> + base = cxl_mem_map_regblock(cxlm, reg_lo, reg_hi);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> break;
> }
> }
> @@ -1031,7 +1029,7 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> return -ENXIO;
> }
>
> - cxl_setup_device_regs(dev, cxlm->base, >device_regs);
> + cxl_setup_device_regs(dev, base, >device_regs);
>
> if (!regs->status || !regs->mbox || !regs->memdev) {
> dev_err(dev, "registers not found: %s%s%s\n",
> diff --git a/drivers/cxl/mem.h b/drivers/cxl/mem.h
> index 8bad7166adba..bfcfef461b16 100644
> --- a/drivers/cxl/mem.h
> +++ b/drivers/cxl/mem.h
> @@ -49,7 +49,6 @@ struct cxl_memdev {
> /**
> * struct cxl_mem - A CXL memory device
> * @pdev: The PCI device associated with this CXL device.
> - * @base: IO mappings to the device's MMIO
> * @cxlmd: Logical memory device chardev / interface
> * @regs: Parsed register blocks
> * @payload_size: Size of space for payload
> @@ -62,7 +61,6 @@ struct cxl_memdev {
> */
> struct cxl_mem {
> struct pci_dev *pdev;
> - void __iomem *base;
> struct cxl_memdev *cxlmd;
>
> struct cxl_regs regs;
Re: [PATCH 1/7] cxl/mem: Use dev instead of pdev->dev
On Wed, 7 Apr 2021 15:26:19 -0700
Ben Widawsky wrote:
> Trivial cleanup.
Obviously correct :)
>
> Signed-off-by: Ben Widawsky
FWIW
Acked-by: Jonathan Cameron
> ---
> drivers/cxl/mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index b6fe4e81d38a..99534260034e 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -935,7 +935,7 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev
> *pdev, u32 reg_lo,
> u8 bar;
> int rc;
>
> - cxlm = devm_kzalloc(>dev, sizeof(*cxlm), GFP_KERNEL);
> + cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
> if (!cxlm) {
> dev_err(dev, "No memory available\n");
> return NULL;
Re: [PATCH 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
On Wed, 7 Apr 2021 21:40:05 +0100 Will Deacon wrote: > On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote: > > PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported > > to sample bandwidth, latency, buffer occupation etc. > > > > Each PMU RCiEP device monitors multiple root ports, and each RCiEP is > > registered as a pmu in /sys/bus/event_source/devices, so users can > > select target PMU, and use filter to do further sets. > > > > Filtering options contains: > > event- select the event. > > subevent - select the subevent. > > port - select target root ports. Information of root ports > >are shown under sysfs. > > bdf - select requester_id of target EP device. > > trig_len - set trigger condition for starting event statistics. > > trigger_mode - set trigger mode. 0 means starting to statistic when > >bigger than trigger condition, and 1 means smaller. > > thr_len - set threshold for statistics. > > thr_mode - set threshold mode. 0 means count when bigger than > >threshold, and 1 means smaller. > > > > Reviewed-by: Jonathan Cameron > > Do you have a link to this review, please? Internal review, so drop the tag. Jonathan > > Will > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v2 11/19] dt-bindings:iio:adc: update dlg,da9150-gpadc.yaml reference
On Wed, 7 Apr 2021 10:20:50 +0200
Mauro Carvalho Chehab wrote:
> Changeset e13b686b18e3 ("dt-bindings:iio:adc:dlg,da9150-gpadc yaml
> conversion")
> renamed: Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt
> to: Documentation/devicetree/bindings/iio/adc/dlg,da9150-gpadc.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: e13b686b18e3 ("dt-bindings:iio:adc:dlg,da9150-gpadc yaml conversion")
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Jonathan Cameron
> ---
> Documentation/devicetree/bindings/mfd/da9150.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/da9150.txt
> b/Documentation/devicetree/bindings/mfd/da9150.txt
> index 763e0b639a82..b7afa39d6260 100644
> --- a/Documentation/devicetree/bindings/mfd/da9150.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9150.txt
> @@ -19,7 +19,7 @@ Required properties:
> further information relating to interrupt properties)
>
> Sub-devices:
> -- da9150-gpadc: See
> Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt
> +- da9150-gpadc: See
> Documentation/devicetree/bindings/iio/adc/dlg,da9150-gpadc.yaml
> - da9150-charger: See
> Documentation/devicetree/bindings/power/da9150-charger.txt
> - da9150-fg: See Documentation/devicetree/bindings/power/da9150-fg.txt
>
Re: [PATCH v2 10/19] dt-bindings:iio:adc: update motorola,cpcap-adc.yaml reference
On Wed, 7 Apr 2021 10:20:49 +0200
Mauro Carvalho Chehab wrote:
> Changeset 1ca9d1b1342d ("dt-bindings:iio:adc:motorola,cpcap-adc yaml
> conversion")
> renamed: Documentation/devicetree/bindings/iio/adc/cpcap-adc.txt
> to: Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 1ca9d1b1342d ("dt-bindings:iio:adc:motorola,cpcap-adc yaml conversion")
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Jonathan Cameron
> ---
> Documentation/devicetree/bindings/mfd/motorola-cpcap.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> index ebdccfb600b9..b52e7a33f0f9 100644
> --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> @@ -23,7 +23,7 @@ which are described in the following files:
> - Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> - Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
> - Documentation/devicetree/bindings/leds/leds-cpcap.txt
> -- Documentation/devicetree/bindings/iio/adc/cpcap-adc.txt
> +- Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml
>
> The only exception is the audio codec. Instead of a compatible value its
> node must be named "audio-codec".
Re: [PATCH v2 07/19] dt-bindings: fix references for iio-bindings.txt
On Wed, 7 Apr 2021 10:20:46 +0200
Mauro Carvalho Chehab wrote:
> The iio-bindings.txt was converted into two files and merged
> at the dt-schema git tree at:
>
> https://github.com/devicetree-org/dt-schema
>
> Yet, some documents still refer to the old file. Fix their
> references, in order to point to the right URL.
>
> Fixes: dba91f82d580 ("dt-bindings:iio:iio-binding.txt Drop file as content
> now in dt-schema")
> Signed-off-by: Mauro Carvalho Chehab
Given the spread of this one across various other binding docs, perhaps this is
one
for Rob to pick up?
Acked-by: Jonathan Cameron
> ---
> Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt | 2 +-
> Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml | 5 +++--
> Documentation/devicetree/bindings/input/adc-joystick.yaml| 4 +++-
> .../bindings/input/touchscreen/resistive-adc-touch.txt | 5 -
> Documentation/devicetree/bindings/mfd/ab8500.txt | 4 +++-
> .../devicetree/bindings/power/supply/da9150-charger.txt | 2 +-
> 6 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> index 37f18d684f6a..4c5c3712970e 100644
> --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
> @@ -32,7 +32,7 @@ Optional node properties:
> - "#thermal-sensor-cells" Used to expose itself to thermal fw.
>
> Read more about iio bindings at
> - Documentation/devicetree/bindings/iio/iio-bindings.txt
> + https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/
>
> Example:
> ncp15wb473@0 {
> diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
> b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
> index 9f414dbdae86..433a3fb55a2e 100644
> --- a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
> @@ -14,8 +14,9 @@ description: >
>Industrial I/O subsystem bindings for ADC controller found in
>Ingenic JZ47xx SoCs.
>
> - ADC clients must use the format described in iio-bindings.txt, giving
> - a phandle and IIO specifier pair ("io-channels") to the ADC controller.
> + ADC clients must use the format described in
> +
> https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/iio-consumer.yaml,
> + giving a phandle and IIO specifier pair ("io-channels") to the ADC
> controller.
>
> properties:
>compatible:
> diff --git a/Documentation/devicetree/bindings/input/adc-joystick.yaml
> b/Documentation/devicetree/bindings/input/adc-joystick.yaml
> index 054406bbd22b..721878d5b7af 100644
> --- a/Documentation/devicetree/bindings/input/adc-joystick.yaml
> +++ b/Documentation/devicetree/bindings/input/adc-joystick.yaml
> @@ -24,7 +24,9 @@ properties:
> description: >
>List of phandle and IIO specifier pairs.
>Each pair defines one ADC channel to which a joystick axis is
> connected.
> - See Documentation/devicetree/bindings/iio/iio-bindings.txt for details.
> + See
> +
> https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/iio-consumer.yaml
> + for details.
>
>'#address-cells':
> const: 1
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> index fee0da12474e..af5223bb5bdd 100644
> ---
> a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> +++
> b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> @@ -5,7 +5,10 @@ Required properties:
> - compatible: must be "resistive-adc-touch"
> The device must be connected to an ADC device that provides channels for
> position measurement and optional pressure.
> -Refer to Documentation/devicetree/bindings/iio/iio-bindings.txt for details
> +Refer to
> +https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/iio-consumer.yaml
> +for details
> +
> - iio-channels: must have at least two channels connected to an ADC device.
> These should correspond to the channels exposed by the ADC device and should
> have the right index as the ADC device registers them. These channels
> diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt
> b/Documentation/devicetree/bindings/mfd/ab8500.txt
> index d2a6e835c257..937b3e5505e0 100644
> --- a/Documentation/devicetree/bindings/mfd/ab8500.txt
> +++ b/Documentation/devi
Re: [PATCH v2 5/8] cxl/acpi: Introduce ACPI0017 driver and cxl_root
On Thu, 1 Apr 2021 07:31:09 -0700
Dan Williams wrote:
> While CXL builds upon the PCI software model for dynamic enumeration and
> control, a static platform component is required to bootstrap the CXL
> memory layout. In addition to identifying the host bridges ACPI is
> responsible for enumerating the CXL memory space that can be addressed
> by decoders. This is similar to the requirement for ACPI to publish
> resources reported by _CRS for PCI host bridges.
>
> Introduce the cxl_root object as an abstract "port" into the CXL.mem
> address space described by HDM decoders identified by the ACPI
> CEDT.CHBS.
>
> For now just establish the initial boilerplate and sysfs attributes, to
> be followed by enumeration of the ports within the host bridge.
>
> Signed-off-by: Dan Williams
A few minor comments inline.
> ---
> drivers/cxl/Kconfig | 14 ++
> drivers/cxl/Makefile |2
> drivers/cxl/acpi.c | 39 ++
> drivers/cxl/core.c | 349
> ++
> drivers/cxl/cxl.h| 64 +
> 5 files changed, 468 insertions(+)
> create mode 100644 drivers/cxl/acpi.c
>
> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> index 97dc4d751651..fb282af84afd 100644
> --- a/drivers/cxl/Kconfig
> +++ b/drivers/cxl/Kconfig
> @@ -50,4 +50,18 @@ config CXL_MEM_RAW_COMMANDS
> potential impact to memory currently in use by the kernel.
>
> If developing CXL hardware or the driver say Y, otherwise say N.
> +
> +config CXL_ACPI
> + tristate "CXL ACPI: Platform Support"
> + depends on ACPI
> + help
> + Enable support for host managed device memory (HDM) resources
> + published by a platform's ACPI CXL memory layout description.
> + See Chapter 9.14.1 CXL Early Discovery Table (CEDT) in the CXL
> + 2.0 specification. The CXL core consumes these resource to
> + publish port and address_space objects used to map regions
> + that represent System RAM, or Persistent Memory regions to be
> + managed by LIBNVDIMM.
> +
> + If unsure say 'm'.
> endif
> diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> index 3808e39dd31f..f429ca6b59d9 100644
> --- a/drivers/cxl/Makefile
> +++ b/drivers/cxl/Makefile
> @@ -1,7 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_CXL_BUS) += cxl_core.o
> obj-$(CONFIG_CXL_MEM) += cxl_mem.o
> +obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
>
> ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> cxl_core-y := core.o
> cxl_mem-y := mem.o
> +cxl_acpi-y := acpi.o
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> new file mode 100644
> index ..d54c2d5de730
> --- /dev/null
> +++ b/drivers/cxl/acpi.c
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright(c) 2021 Intel Corporation. All rights reserved. */
> +#include
> +#include
> +#include
> +#include
> +#include
swap acpi.h that for mod_devicetable.h unless this is going to
need acpi.h later for something else.
> +#include "cxl.h"
> +
> +static int cxl_acpi_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct cxl_root *cxl_root;
> +
> + cxl_root = devm_cxl_add_root(dev, NULL, 0);
> + if (IS_ERR(cxl_root))
> + return PTR_ERR(cxl_root);
> + dev_dbg(dev, "register: %s\n", dev_name(_root->port.dev));
> +
> + return 0;
> +}
> +
> +static const struct acpi_device_id cxl_acpi_ids[] = {
> + { "ACPI0017", 0 },
> + { "", 0 },
> +};
> +MODULE_DEVICE_TABLE(acpi, cxl_acpi_ids);
> +
> +static struct platform_driver cxl_acpi_driver = {
> + .probe = cxl_acpi_probe,
> + .driver = {
> + .name = KBUILD_MODNAME,
> + .acpi_match_table = cxl_acpi_ids,
> + },
> +};
> +
> +module_platform_driver(cxl_acpi_driver);
> +MODULE_LICENSE("GPL v2");
> +MODULE_IMPORT_NS(CXL);
> diff --git a/drivers/cxl/core.c b/drivers/cxl/core.c
> index 2ab467ef9909..46c3b2588d2f 100644
> --- a/drivers/cxl/core.c
> +++ b/drivers/cxl/core.c
> @@ -2,6 +2,8 @@
> /* Copyright(c) 2020-2021 Intel Corporation. All rights reserved. */
> #include
> #include
> +#include
> +#include
> #include "cxl.h"
>
> /**
> @@ -11,6 +13,353 @@
> * point for cross-device interleave coordination through cxl ports.
> */
>
> +static DEFINE_IDA(cxl_port_ida);
> +
> +static ssize_t devtype_show(struct device *dev, struct device_attribute
> *attr,
> + char *buf)
> +{
> + return sysfs_emit(buf, "%s\n", dev->type->name);
> +}
> +static DEVICE_ATTR_RO(devtype);
> +
> +static struct attribute *cxl_base_attributes[] = {
> + _attr_devtype.attr,
> + NULL,
> +};
> +
> +static struct attribute_group cxl_base_attribute_group = {
> + .attrs = cxl_base_attributes,
> +};
> +
> +static struct cxl_address_space *dev_to_address_space(struct device *dev)
> +{
> + struct cxl_address_space_dev *cxl_asd = to_cxl_address_space(dev);
> +
> + return cxl_asd->address_space;
> +}
> +
>
Re: [PATCH v2 7/8] cxl/port: Introduce cxl_port objects
On Thu, 1 Apr 2021 07:31:20 -0700
Dan Williams wrote:
> Once the cxl_root is established then other ports in the hierarchy can
> be attached. The cxl_port object, unlike cxl_root that is associated
> with host bridges, is associated with PCIE Root Ports or PCIE Switch
> Ports. Add cxl_port instances for all PCIE Root Ports in an ACPI0016
> host bridge. The cxl_port instances for PCIE Switch Ports are not
> included here as those are to be modeled as another service device
> registered on the pcie_port_bus_type.
Good to give a bit of description of what port2 represents vs port1.
>
> A sample sysfs topology for a single-host-bridge with
> single-PCIE/CXL-root-port:
>
> /sys/bus/cxl/devices/root0
> ├── address_space0
> │ ├── devtype
> │ ├── end
> │ ├── start
> │ ├── supports_ram
> │ ├── supports_type2
> │ ├── supports_type3
> │ └── uevent
> ├── address_space1
> │ ├── devtype
> │ ├── end
> │ ├── start
> │ ├── supports_pmem
> │ ├── supports_type2
> │ ├── supports_type3
> │ └── uevent
> ├── devtype
> ├── port1
> │ ├── devtype
> │ ├── host -> ../../../../LNXSYSTM:00/LNXSYBUS:00/ACPI0016:00
> │ ├── port2
> │ │ ├── devtype
> │ │ ├── host -> ../../../../../pci:34/:34:00.0
> │ │ ├── subsystem -> ../../../../../../bus/cxl
> │ │ ├── target_id
> │ │ └── uevent
> │ ├── subsystem -> ../../../../../bus/cxl
> │ ├── target_id
> │ └── uevent
> ├── subsystem -> ../../../../bus/cxl
> ├── target_id
> └── uevent
>
> Signed-off-by: Dan Williams
> ---
> drivers/cxl/acpi.c | 99 +++
> drivers/cxl/core.c | 121
>
> drivers/cxl/cxl.h |5 ++
> 3 files changed, 224 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c
> index d54c2d5de730..bc2a35ae880b 100644
> --- a/drivers/cxl/acpi.c
> +++ b/drivers/cxl/acpi.c
> @@ -5,18 +5,117 @@
> #include
> #include
> #include
> +#include
> #include "cxl.h"
>
> +static int match_ACPI0016(struct device *dev, const void *host)
> +{
> + struct acpi_device *adev = to_acpi_device(dev);
> + const char *hid = acpi_device_hid(adev);
> +
> + return strcmp(hid, "ACPI0016") == 0;
> +}
> +
> +struct cxl_walk_context {
> + struct device *dev;
> + struct pci_bus *root;
> + struct cxl_port *port;
> + int error;
> + int count;
> +};
> +
> +static int match_add_root_ports(struct pci_dev *pdev, void *data)
> +{
> + struct cxl_walk_context *ctx = data;
> + struct pci_bus *root_bus = ctx->root;
> + struct cxl_port *port = ctx->port;
> + int type = pci_pcie_type(pdev);
> + struct device *dev = ctx->dev;
> + resource_size_t cxl_regs_phys;
> + int target_id = ctx->count;
> +
> + if (pdev->bus != root_bus)
> + return 0;
> + if (!pci_is_pcie(pdev))
> + return 0;
> + if (type != PCI_EXP_TYPE_ROOT_PORT)
> + return 0;
> +
> + ctx->count++;
> +
> + /* TODO walk DVSEC to find component register base */
> + cxl_regs_phys = -1;
> +
> + port = devm_cxl_add_port(dev, port, >dev, target_id,
> + cxl_regs_phys);
> + if (IS_ERR(port)) {
> + ctx->error = PTR_ERR(port);
> + return ctx->error;
> + }
> +
> + dev_dbg(dev, "%s: register: %s\n", dev_name(>dev),
> + dev_name(>dev));
> +
> + return 0;
> +}
> +
> +/*
> + * A host bridge may contain one or more root ports. Register each port
> + * as a child of the cxl_root.
> + */
> +static int cxl_acpi_register_ports(struct device *dev, struct acpi_device
> *root,
> +struct cxl_port *port, int idx)
> +{
> + struct acpi_pci_root *pci_root = acpi_pci_find_root(root->handle);
> + struct cxl_walk_context ctx;
> +
> + if (!pci_root)
> + return -ENXIO;
> +
> + /* TODO: fold in CEDT.CHBS retrieval */
> + port = devm_cxl_add_port(dev, port, >dev, idx, ~0ULL);
> + if (IS_ERR(port))
> + return PTR_ERR(port);
> + dev_dbg(dev, "%s: register: %s\n", dev_name(>dev),
> + dev_name(>dev));
> +
> + ctx = (struct cxl_walk_context) {
> + .dev = dev,
> + .root = pci_root->bus,
> + .port = port,
> + };
> + pci_walk_bus(pci_root->bus, match_add_root_ports, );
> +
> + if (ctx.count == 0)
> + return -ENODEV;
> + return ctx.error;
> +}
> +
> static int cxl_acpi_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> + struct acpi_device *adev = ACPI_COMPANION(dev);
> + struct device *bridge = NULL;
> struct cxl_root *cxl_root;
> + int rc, i = 0;
>
> cxl_root = devm_cxl_add_root(dev, NULL, 0);
> if (IS_ERR(cxl_root))
> return PTR_ERR(cxl_root);
> dev_dbg(dev, "register: %s\n", dev_name(_root->port.dev));
>
> + while (true) {
> + bridge =
Re: [PATCH v2 2/8] cxl/mem: Introduce 'struct cxl_regs' for "composable" CXL devices
On Thu, 1 Apr 2021 07:30:53 -0700
Dan Williams wrote:
> CXL MMIO register blocks are organized by device type and capabilities.
> There are Component registers, Device registers (yes, an ambiguous
> name), and Memory Device registers (a specific extension of Device
> registers).
>
> It is possible for a given device instance (endpoint or port) to
> implement register sets from multiple of the above categories.
>
> The driver code that enumerates and maps the registers is type specific
> so it is useful to have a dedicated type and helpers for each block
> type.
>
> At the same time, once the registers are mapped the origin type does not
> matter. It is overly pedantic to reference the register block type in
> code that is using the registers.
>
> In preparation for the endpoint driver to incorporate Component registers
> into its MMIO operations reorganize the registers to allow typed
> enumeration + mapping, but anonymous usage. With the end state of
> 'struct cxl_regs' to be:
>
> struct cxl_regs {
> union {
> struct {
> CXL_DEVICE_REGS();
> };
> struct cxl_device_regs device_regs;
> };
> union {
> struct {
> CXL_COMPONENT_REGS();
> };
> struct cxl_component_regs component_regs;
> };
> };
>
> With this arrangement the driver can share component init code with
> ports, but when using the registers it can directly reference the
> component register block type by name without the 'component_regs'
> prefix.
>
> So, map + enumerate can be shared across drivers of different CXL
> classes e.g.:
>
> void cxl_setup_device_regs(struct device *dev, void __iomem *base,
> struct cxl_device_regs *regs);
>
> void cxl_setup_component_regs(struct device *dev, void __iomem *base,
> struct cxl_component_regs *regs);
>
> ...while inline usage in the driver need not indicate where the
> registers came from:
>
> readl(cxlm->regs.mbox + MBOX_OFFSET);
> readl(cxlm->regs.hdm + HDM_OFFSET);
>
> ...instead of:
>
> readl(cxlm->regs.device_regs.mbox + MBOX_OFFSET);
> readl(cxlm->regs.component_regs.hdm + HDM_OFFSET);
>
> This complexity of the definition in .h yields improvement in code
> readability in .c while maintaining type-safety for organization of
> setup code. It prepares the implementation to maintain organization in
> the face of CXL devices that compose register interfaces consisting of
> multiple types.
>
> Reviewed-by: Ben Widawsky
> Signed-off-by: Dan Williams
A few minor things inline.
> ---
> drivers/cxl/cxl.h | 33 +
> drivers/cxl/mem.c | 44
> drivers/cxl/mem.h | 13 +
> 3 files changed, 62 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 2e3bdacb32e7..37325e504fb7 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -34,5 +34,38 @@
> #define CXLDEV_MBOX_BG_CMD_STATUS_OFFSET 0x18
> #define CXLDEV_MBOX_PAYLOAD_OFFSET 0x20
>
> +/* See note for 'struct cxl_regs' for the rationale of this organization */
> +#define CXL_DEVICE_REGS() \
> + void __iomem *status; \
> + void __iomem *mbox; \
> + void __iomem *memdev
> +
> +/**
> + * struct cxl_device_regs - Common container of CXL Device register
> + * block base pointers
> + * @status: CXL 2.0 8.2.8.3 Device Status Registers
> + * @mbox: CXL 2.0 8.2.8.4 Mailbox Registers
> + * @memdev: CXL 2.0 8.2.8.5 Memory Device Registers
kernel-doc script is not going to be happy with documenting fields it can't see
+ not documenting the CXL_DEVICE_REGS() field it can.
I've no idea what the right way to handle this might be.
> + */
> +struct cxl_device_regs {
> + CXL_DEVICE_REGS();
> +};
> +
> +/*
> + * Note, the anonymous union organization allows for per
> + * register-block-type helper routines, without requiring block-type
> + * agnostic code to include the prefix. I.e.
> + * cxl_setup_device_regs(>regs.dev) vs readl(cxlm->regs.mbox).
> + * The specificity reads naturally from left-to-right.
> + */
> +struct cxl_regs {
> + union {
> + struct {
> + CXL_DEVICE_REGS();
> + };
> + struct cxl_device_regs device_regs;
> + };
> +};
> +
> extern struct bus_type cxl_bus_type;
> #endif /* __CXL_H__ */
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 45871ef65152..6951243d128e 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -31,7 +31,7 @@
> */
>
> #define cxl_doorbell_busy(cxlm)
> \
> - (readl((cxlm)->mbox_regs + CXLDEV_MBOX_CTRL_OFFSET) & \
> + (readl((cxlm)->regs.mbox + CXLDEV_MBOX_CTRL_OFFSET) & \
>CXLDEV_MBOX_CTRL_DOORBELL)
>
> /* CXL 2.0 - 8.2.8.4 */
> @@ -271,7 +271,7 @@
Re: [PATCH v2 4/8] cxl/core: Refactor CXL register lookup for bridge reuse
On Thu, 1 Apr 2021 07:31:03 -0700
Dan Williams wrote:
> While CXL Memory Device endpoints locate the CXL MMIO registers in a PCI
> BAR, CXL root bridges have their MMIO base address described by platform
> firmware. Refactor the existing register lookup into a generic facility
> for endpoints and bridges to share.
>
> Reviewed-by: Ben Widawsky
> Signed-off-by: Dan Williams
Nice to make the docs kernel-doc, but otherwise this is simple and makes sense
Reviewed-by: Jonathan Cameron
> ---
> drivers/cxl/core.c | 57
> +++-
> drivers/cxl/cxl.h |3 +++
> drivers/cxl/mem.c | 50 +-
> 3 files changed, 65 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/cxl/core.c b/drivers/cxl/core.c
> index 7f8d2034038a..2ab467ef9909 100644
> --- a/drivers/cxl/core.c
> +++ b/drivers/cxl/core.c
> @@ -1,7 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0-only
> -/* Copyright(c) 2020 Intel Corporation. All rights reserved. */
> +/* Copyright(c) 2020-2021 Intel Corporation. All rights reserved. */
> #include
> #include
> +#include "cxl.h"
>
> /**
> * DOC: cxl core
> @@ -10,6 +11,60 @@
> * point for cross-device interleave coordination through cxl ports.
> */
>
> +/*
> + * cxl_setup_device_regs() - Detect CXL Device register blocks
> + * @dev: Host device of the @base mapping
> + * @base: mapping of CXL 2.0 8.2.8 CXL Device Register Interface
Not much to add to make this kernel-doc. Just the one missing parameter
and mark it /** Given it's exported, it would be nice to tidy that up.
> + */
> +void cxl_setup_device_regs(struct device *dev, void __iomem *base,
> +struct cxl_device_regs *regs)
> +{
> + int cap, cap_count;
> + u64 cap_array;
> +
> + *regs = (struct cxl_device_regs) { 0 };
> +
> + cap_array = readq(base + CXLDEV_CAP_ARRAY_OFFSET);
> + if (FIELD_GET(CXLDEV_CAP_ARRAY_ID_MASK, cap_array) !=
> + CXLDEV_CAP_ARRAY_CAP_ID)
> + return;
> +
> + cap_count = FIELD_GET(CXLDEV_CAP_ARRAY_COUNT_MASK, cap_array);
> +
> + for (cap = 1; cap <= cap_count; cap++) {
> + void __iomem *register_block;
> + u32 offset;
> + u16 cap_id;
> +
> + cap_id = FIELD_GET(CXLDEV_CAP_HDR_CAP_ID_MASK,
> +readl(base + cap * 0x10));
> + offset = readl(base + cap * 0x10 + 0x4);
> + register_block = base + offset;
> +
> + switch (cap_id) {
> + case CXLDEV_CAP_CAP_ID_DEVICE_STATUS:
> + dev_dbg(dev, "found Status capability (0x%x)\n",
> offset);
> + regs->status = register_block;
> + break;
> + case CXLDEV_CAP_CAP_ID_PRIMARY_MAILBOX:
> + dev_dbg(dev, "found Mailbox capability (0x%x)\n",
> offset);
> + regs->mbox = register_block;
> + break;
> + case CXLDEV_CAP_CAP_ID_SECONDARY_MAILBOX:
> + dev_dbg(dev, "found Secondary Mailbox capability
> (0x%x)\n", offset);
> + break;
> + case CXLDEV_CAP_CAP_ID_MEMDEV:
> + dev_dbg(dev, "found Memory Device capability (0x%x)\n",
> offset);
> + regs->memdev = register_block;
> + break;
> + default:
> + dev_dbg(dev, "Unknown cap ID: %d (0x%x)\n", cap_id,
> offset);
> + break;
> + }
> + }
> +}
> +EXPORT_SYMBOL_GPL(cxl_setup_device_regs);
> +
> struct bus_type cxl_bus_type = {
> .name = "cxl",
> };
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 37325e504fb7..cbd29650c4e2 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -67,5 +67,8 @@ struct cxl_regs {
> };
> };
>
> +void cxl_setup_device_regs(struct device *dev, void __iomem *base,
> +struct cxl_device_regs *regs);
> +
> extern struct bus_type cxl_bus_type;
> #endif /* __CXL_H__ */
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 6951243d128e..ee55abfa147e 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -865,53 +865,15 @@ static int cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm,
> u16 opcode,
> static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> {
> struct device *dev = >pdev->dev;
> - int cap, cap_count;
> - u64 cap_array;
> + struct cxl_regs *regs = >regs;
>
&
Re: [PATCH v2 1/8] cxl/mem: Move some definitions to mem.h
On Thu, 1 Apr 2021 07:30:47 -0700
Dan Williams wrote:
> In preparation for sharing cxl.h with other generic CXL consumers,
> move / consolidate some of the memory device specifics to mem.h.
>
> Reviewed-by: Ben Widawsky
> Signed-off-by: Dan Williams
Hi Dan,
Would be good to see something in this patch description saying
why you chose to have mem.h rather than push the defines down
into mem.c (which from the current code + patch set looks like
the more logical thing to do).
As a side note, docs for struct cxl_mem need a fix as they cover
enabled_commands which at somepoint got shortened to enabled_cmds
Jonathan
> ---
> drivers/cxl/cxl.h | 57
> drivers/cxl/mem.c | 25 +---
> drivers/cxl/mem.h | 85
> +
> 3 files changed, 86 insertions(+), 81 deletions(-)
> create mode 100644 drivers/cxl/mem.h
>
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 6f14838c2d25..2e3bdacb32e7 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -34,62 +34,5 @@
> #define CXLDEV_MBOX_BG_CMD_STATUS_OFFSET 0x18
> #define CXLDEV_MBOX_PAYLOAD_OFFSET 0x20
>
> -/* CXL 2.0 8.2.8.5.1.1 Memory Device Status Register */
> -#define CXLMDEV_STATUS_OFFSET 0x0
> -#define CXLMDEV_DEV_FATAL BIT(0)
> -#define CXLMDEV_FW_HALT BIT(1)
> -#define CXLMDEV_STATUS_MEDIA_STATUS_MASK GENMASK(3, 2)
> -#define CXLMDEV_MS_NOT_READY 0
> -#define CXLMDEV_MS_READY 1
> -#define CXLMDEV_MS_ERROR 2
> -#define CXLMDEV_MS_DISABLED 3
> -#define CXLMDEV_READY(status)
> \
> - (FIELD_GET(CXLMDEV_STATUS_MEDIA_STATUS_MASK, status) ==\
> - CXLMDEV_MS_READY)
> -#define CXLMDEV_MBOX_IF_READY BIT(4)
> -#define CXLMDEV_RESET_NEEDED_MASK GENMASK(7, 5)
> -#define CXLMDEV_RESET_NEEDED_NOT 0
> -#define CXLMDEV_RESET_NEEDED_COLD 1
> -#define CXLMDEV_RESET_NEEDED_WARM 2
> -#define CXLMDEV_RESET_NEEDED_HOT 3
> -#define CXLMDEV_RESET_NEEDED_CXL 4
> -#define CXLMDEV_RESET_NEEDED(status)
> \
> - (FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) != \
> - CXLMDEV_RESET_NEEDED_NOT)
> -
> -struct cxl_memdev;
> -/**
> - * struct cxl_mem - A CXL memory device
> - * @pdev: The PCI device associated with this CXL device.
> - * @regs: IO mappings to the device's MMIO
> - * @status_regs: CXL 2.0 8.2.8.3 Device Status Registers
> - * @mbox_regs: CXL 2.0 8.2.8.4 Mailbox Registers
> - * @memdev_regs: CXL 2.0 8.2.8.5 Memory Device Registers
> - * @payload_size: Size of space for payload
> - *(CXL 2.0 8.2.8.4.3 Mailbox Capabilities Register)
> - * @mbox_mutex: Mutex to synchronize mailbox access.
> - * @firmware_version: Firmware version for the memory device.
> - * @enabled_commands: Hardware commands found enabled in CEL.
> - * @pmem_range: Persistent memory capacity information.
> - * @ram_range: Volatile memory capacity information.
> - */
> -struct cxl_mem {
> - struct pci_dev *pdev;
> - void __iomem *regs;
> - struct cxl_memdev *cxlmd;
> -
> - void __iomem *status_regs;
> - void __iomem *mbox_regs;
> - void __iomem *memdev_regs;
> -
> - size_t payload_size;
> - struct mutex mbox_mutex; /* Protects device mailbox and firmware */
> - char firmware_version[0x10];
> - unsigned long *enabled_cmds;
> -
> - struct range pmem_range;
> - struct range ram_range;
> -};
> -
> extern struct bus_type cxl_bus_type;
> #endif /* __CXL_H__ */
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 244cb7d89678..45871ef65152 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -12,6 +12,7 @@
> #include
> #include "pci.h"
> #include "cxl.h"
> +#include "mem.h"
>
> /**
> * DOC: cxl mem
> @@ -29,12 +30,6 @@
> * - Handle and manage error conditions.
> */
>
> -/*
> - * An entire PCI topology full of devices should be enough for any
> - * config
> - */
> -#define CXL_MEM_MAX_DEVS 65536
> -
> #define cxl_doorbell_busy(cxlm)
> \
> (readl((cxlm)->mbox_regs + CXLDEV_MBOX_CTRL_OFFSET) & \
>CXLDEV_MBOX_CTRL_DOORBELL)
> @@ -91,24 +86,6 @@ struct mbox_cmd {
> #define CXL_MBOX_SUCCESS 0
> };
>
> -/**
> - * struct cxl_memdev - CXL bus object representing a Type-3 Memory Device
> - * @dev: driver core device object
> - * @cdev: char dev core object for ioctl operations
> - * @cxlm: pointer to the parent device driver data
> - * @ops_active: active user of @cxlm in ops handlers
> - * @ops_dead: completion when all @cxlm ops users have exited
> - * @id: id number of this memdev instance.
> - */
> -struct cxl_memdev {
> - struct device dev;
> - struct cdev cdev;
> - struct cxl_mem *cxlm;
> - struct percpu_ref ops_active;
> - struct completion ops_dead;
> - int id;
> -};
> -
Why move this stuff? As
Re: [PATCH][next] iio: hrtimer-trigger: Fix potential integer overflow in iio_hrtimer_store_sampling_frequency
On Mon, 29 Mar 2021 15:58:17 -0500
"Gustavo A. R. Silva" wrote:
> Add suffix ULL to constant 1000 in order to avoid a potential integer
> overflow and give the compiler complete information about the proper
> arithmetic to use. Notice that this constant is being used in a context
> that expects an expression of type unsigned long long, but it's
> currently evaluated using 32-bit arithmetic.
>
> Addresses-Coverity-ID: 1503062 ("Unintentional integer overflow")
> Fixes: dafcf4ed8392 ("iio: hrtimer: Allow sub Hz granularity")
> Signed-off-by: Gustavo A. R. Silva
Thanks, Applied to the togreg branch of iio.git and pushed out as testing
for 0-day to poke at it.
Thanks,
Jonathan
> ---
> drivers/iio/trigger/iio-trig-hrtimer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c
> b/drivers/iio/trigger/iio-trig-hrtimer.c
> index 51e362f091c2..716c795d08fb 100644
> --- a/drivers/iio/trigger/iio-trig-hrtimer.c
> +++ b/drivers/iio/trigger/iio-trig-hrtimer.c
> @@ -63,7 +63,7 @@ ssize_t iio_hrtimer_store_sampling_frequency(struct device
> *dev,
> if (integer < 0 || fract < 0)
> return -ERANGE;
>
> - val = fract + 1000 * integer; /* mHz */
> + val = fract + 1000ULL * integer; /* mHz */
>
> if (!val || val > UINT_MAX)
> return -EINVAL;
Re: [PATCH v7 1/2] Added AMS tsl2591 driver implementation
On Fri, 2 Apr 2021 01:45:46 +0100 Joe Sandom wrote: > Driver implementation for AMS/TAOS tsl2591 ambient light sensor. > > This driver supports configuration via device tree and sysfs. > Supported channels for raw infrared light intensity, > raw combined light intensity and illuminance in lux. > The driver additionally supports iio events on lower and > upper thresholds. > > This is a very-high sensitivity light-to-digital converter that > transforms light intensity into a digital signal. > > Datasheet: https://ams.com/tsl25911#tab/documents > > Signed-off-by: Joe Sandom Hi Joe, One thing I noticed whilst reading this that I'd missed before is we present userspace with the interface for events whether or not we have an IRQ. It would be nice to tidy that up. If nothing else comes up in review, I can do that whilst applying as it's pretty straight forward. I'd like to leave this a little longer on list though to see if anyone else would like to take a last look. Thanks, Jonathan > --- > > Changes in v7; > - Revert back to using plain numbers in register defines instead of BIT and > GENMASK > - Changed from pre-increment of 'i' in for loops to post-increment > - Use iopoll.h - readx_poll_timeout macro for periodic poll on ALS status > flag valid > - Remove the 0xFF masks on u8 types as they are redundant > > drivers/iio/light/Kconfig | 11 + > drivers/iio/light/Makefile |1 + > drivers/iio/light/tsl2591.c | 1224 +++ > 3 files changed, 1236 insertions(+) > create mode 100644 drivers/iio/light/tsl2591.c > > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > index 33ad4dd0b5c7..6a69a9a3577a 100644 > --- a/drivers/iio/light/Kconfig > +++ b/drivers/iio/light/Kconfig > @@ -501,6 +501,17 @@ config TSL2583 > Provides support for the TAOS tsl2580, tsl2581 and tsl2583 devices. > Access ALS data via iio, sysfs. > > +config TSL2591 > +tristate "TAOS TSL2591 ambient light sensor" > +depends on I2C > +help > + Select Y here for support of the AMS/TAOS TSL2591 ambient light > sensor, > + featuring channels for combined visible + IR intensity and lux > illuminance. > + Access data via iio and sysfs. Supports iio_events. > + > + To compile this driver as a module, select M: the > + module will be called tsl2591. > + > config TSL2772 > tristate "TAOS TSL/TMD2x71 and TSL/TMD2x72 Family of light and > proximity sensors" > depends on I2C > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > index ea376deaca54..d10912faf964 100644 > --- a/drivers/iio/light/Makefile > +++ b/drivers/iio/light/Makefile > @@ -48,6 +48,7 @@ obj-$(CONFIG_ST_UVIS25_SPI) += st_uvis25_spi.o > obj-$(CONFIG_TCS3414)+= tcs3414.o > obj-$(CONFIG_TCS3472)+= tcs3472.o > obj-$(CONFIG_TSL2583)+= tsl2583.o > +obj-$(CONFIG_TSL2591)+= tsl2591.o > obj-$(CONFIG_TSL2772)+= tsl2772.o > obj-$(CONFIG_TSL4531)+= tsl4531.o > obj-$(CONFIG_US5182D)+= us5182d.o > diff --git a/drivers/iio/light/tsl2591.c b/drivers/iio/light/tsl2591.c > new file mode 100644 > index ..14a405a96e3a > --- /dev/null > +++ b/drivers/iio/light/tsl2591.c > @@ -0,0 +1,1224 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Copyright (C) 2020 Joe Sandom > + * > + * Datasheet: https://ams.com/tsl25911#tab/documents > + * > + * Device driver for the TAOS TSL2591. This is a very-high sensitivity > + * light-to-digital converter that transforms light intensity into a digital > + * signal. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +/* ADC integration time, field value to time in ms*/ > +#define TSL2591_FVAL_TO_ATIME(x) (((x) + 1) * 100) > +/* ADC integration time, time in ms to field value */ > +#define TSL2591_ATIME_TO_FVAL(x) (((x) / 100) - 1) > + > +/* TSL2591 register set */ > +#define TSL2591_ENABLE 0x00 > +#define TSL2591_CONTROL 0x01 > +#define TSL2591_AILTL 0x04 > +#define TSL2591_AILTH 0x05 > +#define TSL2591_AIHTL 0x06 > +#define TSL2591_AIHTH 0x07 > +#define TSL2591_NP_AILTL0x08 > +#define TSL2591_NP_AILTH0x09 > +#define TSL2591_NP_AIHTL0x0A > +#define TSL2591_NP_AIHTH0x0B > +#define TSL2591_PERSIST 0x0C > +#define TSL2591_PACKAGE_ID 0x11 > +#define TSL2591_DEVICE_ID 0x12 > +#define TSL2591_STATUS 0x13 > +#define TSL2591_C0_DATAL0x14 > +#define TSL2591_C0_DATAH0x15 > +#define TSL2591_C1_DATAL0x16 > +#define TSL2591_C1_DATAH0x17 > + > +/* TSL2591 command register definitions */ > +#define TSL2591_CMD_NOP 0xA0 > +#define TSL2591_CMD_SF_INTSET 0xE4 > +#define TSL2591_CMD_SF_CALS_I 0xE5 > +#define
Re: [PATCH] iio: buffer: use sysfs_attr_init() on allocated attrs
On Fri, 2 Apr 2021 20:42:26 +0300
Alexandru Ardelean wrote:
> When dynamically allocating sysfs attributes, it's a good idea to call
> sysfs_attr_init() on them to initialize lock_class_keys.
> This change does that.
>
> The lock_class_keys are set when the CONFIG_DEBUG_LOCK_ALLOC symbol is
> enabled. Which is [likely] one reason why I did not see this during
> development.
>
> I also am not able to see this even with CONFIG_DEBUG_LOCK_ALLOC enabled,
> so this may [likely] be reproduce-able on some system configurations.
>
> This was reported via:
>
> https://lore.kernel.org/linux-iio/CA+U=DsrsvGgXEF30-vXuXS_k=-mjsjibweezwkb1hjvn1p9...@mail.gmail.com/T/#u
>
> Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into
> iio_dev_attr")
> Reported-by: Marek Szyprowski
> Signed-off-by: Alexandru Ardelean
> ---
>
> @Marek: could you maybe test this on your setup?
>
> I haven't been able to reproduce this on mine.
I'm fairly sure this is the right fix, and 'should' resolve the issue Marek
saw so I'm going to queue it up.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to poke at it and see if we missed anything.
Thanks,
Jonathan
>
> Thanks
> Alex
>
> drivers/iio/industrialio-buffer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/industrialio-buffer.c
> b/drivers/iio/industrialio-buffer.c
> index ee5aab9d4a23..06b2ea087408 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -1309,6 +1309,7 @@ static struct attribute *iio_buffer_wrap_attr(struct
> iio_buffer *buffer,
> iio_attr->buffer = buffer;
> memcpy(_attr->dev_attr, dattr, sizeof(iio_attr->dev_attr));
> iio_attr->dev_attr.attr.name = kstrdup_const(attr->name, GFP_KERNEL);
> + sysfs_attr_init(_attr->dev_attr.attr);
>
> list_add(_attr->l, >buffer_attr_list);
>
Re: [PATCH v2 1/2] iio: trigger: Replace explicit casting and wrong specifier with proper one
On Fri, 2 Apr 2021 20:49:10 +0300 Andy Shevchenko wrote: > By unknown reason device name is set with an index casted from int > to unsigned long while at the same time with "%ld" specifier. Both parts > seems wrong to me, thus replace replace explicit casting and wrong specifier > with proper one, i.e. "%d". > > Signed-off-by: Andy Shevchenko Series applied to the togreg branch of iio.git. thanks, Jonathan > --- > v2: used %d which is really correct one > drivers/iio/industrialio-trigger.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/iio/industrialio-trigger.c > b/drivers/iio/industrialio-trigger.c > index 32ac1bec25e3..78e30f0f915c 100644 > --- a/drivers/iio/industrialio-trigger.c > +++ b/drivers/iio/industrialio-trigger.c > @@ -75,8 +75,7 @@ int __iio_trigger_register(struct iio_trigger *trig_info, > return trig_info->id; > > /* Set the name used for the sysfs directory etc */ > - dev_set_name(_info->dev, "trigger%ld", > - (unsigned long) trig_info->id); > + dev_set_name(_info->dev, "trigger%d", trig_info->id); > > ret = device_add(_info->dev); > if (ret)
Re: [PATCH] iio: adc: stm32-dfsdm: drop __func__ while using Dynamic debug
On Thu, 1 Apr 2021 21:05:58 +0300
Andy Shevchenko wrote:
> On Thu, Apr 1, 2021 at 8:48 PM Mugilraj Dhavachelvan
> wrote:
> >
> > dropped __func__ while using dev_dbg() and pr_debug()
>
> The commit message may be amended, from code perspective LGTM!
> Reviewed-by: Andy Shevchenko
I added a note to the commit message to observe that the function
name printing can be configured using dynamic debug.
Applied to the togreg branch of iio.git and pushed out as testing
to let the autobuilder bots like 0-day check if they can find any
problems that we've missed.
Thanks,
Jonathan
>
> > Signed-off-by: Mugilraj Dhavachelvan
> > ---
> > drivers/iio/adc/stm32-dfsdm-adc.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c
> > b/drivers/iio/adc/stm32-dfsdm-adc.c
> > index 76a60d93fe23..95ec5f3c3126 100644
> > --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> > +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> > @@ -198,7 +198,7 @@ static int stm32_dfsdm_compute_osrs(struct
> > stm32_dfsdm_filter *fl,
> > unsigned int p = fl->ford; /* filter order (ford) */
> > struct stm32_dfsdm_filter_osr *flo = >flo[fast];
> >
> > - pr_debug("%s: Requested oversampling: %d\n", __func__, oversamp);
> > + pr_debug("Requested oversampling: %d\n", oversamp);
> > /*
> > * This function tries to compute filter oversampling and integrator
> > * oversampling, base on oversampling ratio requested by user.
> > @@ -294,8 +294,8 @@ static int stm32_dfsdm_compute_osrs(struct
> > stm32_dfsdm_filter *fl,
> > }
> > flo->max = (s32)max;
> >
> > - pr_debug("%s: fast %d, fosr %d, iosr %d,
> > res 0x%llx/%d bits, rshift %d, lshift %d\n",
> > -__func__, fast, flo->fosr,
> > flo->iosr,
> > + pr_debug("fast %d, fosr %d, iosr %d, res
> > 0x%llx/%d bits, rshift %d, lshift %d\n",
> > +fast, flo->fosr, flo->iosr,
> > flo->res, bits, flo->rshift,
> > flo->lshift);
> > }
> > @@ -858,7 +858,7 @@ static void stm32_dfsdm_dma_buffer_done(void *data)
> > * support in IIO.
> > */
> >
> > - dev_dbg(_dev->dev, "%s: pos = %d, available = %d\n", __func__,
> > + dev_dbg(_dev->dev, "pos = %d, available = %d\n",
> > adc->bufi, available);
> > old_pos = adc->bufi;
> >
> > @@ -912,7 +912,7 @@ static int stm32_dfsdm_adc_dma_start(struct iio_dev
> > *indio_dev)
> > if (!adc->dma_chan)
> > return -EINVAL;
> >
> > - dev_dbg(_dev->dev, "%s size=%d watermark=%d\n", __func__,
> > + dev_dbg(_dev->dev, "size=%d watermark=%d\n",
> > adc->buf_sz, adc->buf_sz / 2);
> >
> > if (adc->nconv == 1 && !indio_dev->trig)
> > --
> > 2.25.1
> >
>
>
Re: [PATCH v1 1/2] iio: trigger: Replace explicit casting and wrong specifier with proper one
On Thu, 1 Apr 2021 17:54:56 +0300 Andy Shevchenko wrote: > By unknown reason device name is set with an index casted from int > to unsigned long while at the same time with "%ld" specifier. Both parts > seems wrong to me, thus replace replace explicit casting and wrong specifier > with proper one, i.e. "%u". I'm not going to pretend to know what planet I was on when I wrote this :) Series applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to poke at. Thanks, Jonathan > > Signed-off-by: Andy Shevchenko > --- > drivers/iio/industrialio-trigger.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/iio/industrialio-trigger.c > b/drivers/iio/industrialio-trigger.c > index 32ac1bec25e3..77fca24147b2 100644 > --- a/drivers/iio/industrialio-trigger.c > +++ b/drivers/iio/industrialio-trigger.c > @@ -75,8 +75,7 @@ int __iio_trigger_register(struct iio_trigger *trig_info, > return trig_info->id; > > /* Set the name used for the sysfs directory etc */ > - dev_set_name(_info->dev, "trigger%ld", > - (unsigned long) trig_info->id); > + dev_set_name(_info->dev, "trigger%u", trig_info->id); > > ret = device_add(_info->dev); > if (ret)
Re: [PATCH 25/32] dt-bindings:iio:dac: update microchip,mcp4725.yaml reference
On Thu, 1 Apr 2021 14:17:45 +0200
Mauro Carvalho Chehab wrote:
> Changeset 6ced946a4bba ("dt-bindings:iio:dac:microchip,mcp4725 yaml
> conversion")
> renamed: Documentation/devicetree/bindings/iio/dac/mcp4725.txt
> to: Documentation/devicetree/bindings/iio/dac/microchip,mcp4725.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 6ced946a4bba ("dt-bindings:iio:dac:microchip,mcp4725 yaml conversion")
> Signed-off-by: Mauro Carvalho Chehab
Applied thanks.
Jonathan
> ---
> include/linux/iio/dac/mcp4725.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/iio/dac/mcp4725.h b/include/linux/iio/dac/mcp4725.h
> index e9801c8d49c0..1f7e53c506b6 100644
> --- a/include/linux/iio/dac/mcp4725.h
> +++ b/include/linux/iio/dac/mcp4725.h
> @@ -15,7 +15,7 @@
> * @vref_buffered: Controls buffering of the external reference voltage.
> *
> * Vref related settings are available only on MCP4756. See
> - * Documentation/devicetree/bindings/iio/dac/mcp4725.txt for more
> information.
> + * Documentation/devicetree/bindings/iio/dac/microchip,mcp4725.yaml for more
> information.
> */
> struct mcp4725_platform_data {
> bool use_vref;
Re: [PATCH 21/32] MAINTAINERS: update ti,dac7612.yaml reference
On Thu, 1 Apr 2021 14:17:41 +0200
Mauro Carvalho Chehab wrote:
> Changeset 8b74e06b0f4d ("dt-bindings:iio:dac:ti,dac7612 yaml conversion")
> renamed: Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> to: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 8b74e06b0f4d ("dt-bindings:iio:dac:ti,dac7612 yaml conversion")
> Signed-off-by: Mauro Carvalho Chehab
Applied,
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6b0a6f251e6b..2f63ebd2cfc8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17907,7 +17907,7 @@ TEXAS INSTRUMENTS' DAC7612 DAC DRIVER
> M: Ricardo Ribalda
> L: linux-...@vger.kernel.org
> S: Supported
> -F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> +F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
> F: drivers/iio/dac/ti-dac7612.c
>
> TEXAS INSTRUMENTS DMA DRIVERS
Re: [PATCH 19/32] MAINTAINERS: update st,vl53l0x.yaml reference
On Thu, 1 Apr 2021 14:17:39 +0200
Mauro Carvalho Chehab wrote:
> Changeset b4be8bd1c6a2 ("dt-bindings:iio:proximity:st,vl53l0x yaml
> conversion")
> renamed: Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> to: Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: b4be8bd1c6a2 ("dt-bindings:iio:proximity:st,vl53l0x yaml conversion")
> Signed-off-by: Mauro Carvalho Chehab
Applied,
Thanks,
Jonathan
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 54c469933f66..d6708b3fdbd9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17171,7 +17171,7 @@ ST VL53L0X ToF RANGER(I2C) IIO DRIVER
> M: Song Qiang
> L: linux-...@vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> +F: Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml
> F: drivers/iio/proximity/vl53l0x-i2c.c
>
> STABLE BRANCH
Re: [PATCH 18/32] MAINTAINERS: update st,lsm6dsx.yaml reference
On Thu, 1 Apr 2021 14:17:38 +0200
Mauro Carvalho Chehab wrote:
> Changeset 7a2cf8e91390 ("dt-bindings:iio:imu:st,lsm6dsx: txt to yaml
> conversion")
> renamed: Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
> to: Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 7a2cf8e91390 ("dt-bindings:iio:imu:st,lsm6dsx: txt to yaml conversion")
> Signed-off-by: Mauro Carvalho Chehab
Applied,
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 97763e68b8e3..54c469933f66 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17142,7 +17142,7 @@ M:Lorenzo Bianconi
> L: linux-...@vger.kernel.org
> S: Maintained
> W: http://www.st.com/
> -F: Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
> +F: Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
> F: drivers/iio/imu/st_lsm6dsx/
>
> ST MIPID02 CSI-2 TO PARALLEL BRIDGE DRIVER
Re: [PATCH 17/32] MAINTAINERS: update renesas,rcar-gyroadc.yaml reference
On Thu, 1 Apr 2021 14:17:37 +0200
Mauro Carvalho Chehab wrote:
> Changeset 8c41245872e2 ("dt-bindings:iio:adc:renesas,rcar-gyroadc: txt to
> yaml conversion.")
> renamed: Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
> to: Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 8c41245872e2 ("dt-bindings:iio:adc:renesas,rcar-gyroadc: txt to yaml
> conversion.")
> Signed-off-by: Mauro Carvalho Chehab
Applied
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 636b29fd2d4b..97763e68b8e3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15437,7 +15437,7 @@ RENESAS R-CAR GYROADC DRIVER
> M: Marek Vasut
> L: linux-...@vger.kernel.org
> S: Supported
> -F: Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
> +F: Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml
> F: drivers/iio/adc/rcar-gyroadc.c
>
> RENESAS R-CAR I2C DRIVERS
Re: [PATCH 16/32] MAINTAINERS: update pni,rm3100.yaml reference
On Thu, 1 Apr 2021 14:17:36 +0200
Mauro Carvalho Chehab wrote:
> Changeset f383069be33e ("dt-bindings:iio:magnetometer:pni,rm3100: txt to yaml
> conversion.")
> renamed: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
> to: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: f383069be33e ("dt-bindings:iio:magnetometer:pni,rm3100: txt to yaml
> conversion.")
> Signed-off-by: Mauro Carvalho Chehab
Applied
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 89ed435ca6c3..636b29fd2d4b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14445,7 +14445,7 @@ PNI RM3100 IIO DRIVER
> M: Song Qiang
> L: linux-...@vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
> +F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.yaml
> F: drivers/iio/magnetometer/rm3100*
>
> PNP SUPPORT
Re: [PATCH 15/32] MAINTAINERS: update atmel,sama5d2-adc.yaml reference
On Thu, 1 Apr 2021 14:17:35 +0200
Mauro Carvalho Chehab wrote:
> Changeset 58ff1b519753 ("dt-bindings:iio:adc:atmel,sama5d2-adc: txt to yaml
> conversion")
> renamed: Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> to: Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 58ff1b519753 ("dt-bindings:iio:adc:atmel,sama5d2-adc: txt to yaml
> conversion")
> Signed-off-by: Mauro Carvalho Chehab
Applied
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 576d1bcabb20..89ed435ca6c3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11930,7 +11930,7 @@ MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER
> M: Eugen Hristev
> L: linux-...@vger.kernel.org
> S: Supported
> -F: Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> +F: Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml
> F: drivers/iio/adc/at91-sama5d2_adc.c
> F: include/dt-bindings/iio/adc/at91-sama5d2_adc.h
>
Re: [PATCH 11/32] MAINTAINERS: update invensense,mpu3050.yaml reference
On Thu, 1 Apr 2021 14:17:31 +0200
Mauro Carvalho Chehab wrote:
> Changeset 749787477ae4 ("dt-bindings:iio:gyro:invensense,mpu3050: txt to yaml
> format conversion.")
> renamed:
> Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.txt
> to: Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 749787477ae4 ("dt-bindings:iio:gyro:invensense,mpu3050: txt to yaml
> format conversion.")
> Signed-off-by: Mauro Carvalho Chehab
Applied
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5110f47ebf85..ce675a0b3819 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9414,7 +9414,7 @@ INVENSENSE MPU-3050 GYROSCOPE DRIVER
> M: Linus Walleij
> L: linux-...@vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.txt
> +F: Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml
> F: drivers/iio/gyro/mpu3050*
>
> IOC3 ETHERNET DRIVER
Re: [PATCH 10/32] MAINTAINERS: update voltage-divider.yaml reference
On Thu, 1 Apr 2021 14:17:30 +0200
Mauro Carvalho Chehab wrote:
> Changeset 6f633bc91ac1 ("dt-bindings:iio:afe:voltage-divider: txt to yaml
> conversion")
> renamed: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> to: Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 6f633bc91ac1 ("dt-bindings:iio:afe:voltage-divider: txt to yaml
> conversion")
> Signed-off-by: Mauro Carvalho Chehab
Applied.
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 71950316c736..5110f47ebf85 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8797,7 +8797,7 @@ L: linux-...@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
> F: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml
> -F: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> +F: Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml
> F: drivers/iio/afe/iio-rescale.c
>
> IKANOS/ADI EAGLE ADSL USB DRIVER
Re: [PATCH 09/32] MAINTAINERS: update current-sense-shunt.yaml reference
On Thu, 1 Apr 2021 14:17:29 +0200
Mauro Carvalho Chehab wrote:
> Changeset ce66e52b6c16 ("dt-bindings:iio:afe:current-sense-shunt: txt to yaml
> conversion.")
> renamed: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> to: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: ce66e52b6c16 ("dt-bindings:iio:afe:current-sense-shunt: txt to yaml
> conversion.")
> Signed-off-by: Mauro Carvalho Chehab
Applied.
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c7168833da8f..71950316c736 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8796,7 +8796,7 @@ M: Peter Rosin
> L: linux-...@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
> -F: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> +F: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml
> F: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> F: drivers/iio/afe/iio-rescale.c
>
Re: [PATCH 08/32] MAINTAINERS: update current-sense-amplifier.yaml reference
On Thu, 1 Apr 2021 14:17:28 +0200
Mauro Carvalho Chehab wrote:
> Changeset fbac26b9ad21 ("dt-bindings:iio:afe:current-sense-amplifier: txt to
> yaml conversion.")
> renamed: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
> to: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: fbac26b9ad21 ("dt-bindings:iio:afe:current-sense-amplifier: txt to
> yaml conversion.")
> Signed-off-by: Mauro Carvalho Chehab
Applied.
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 82220a72eba2..c7168833da8f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8795,7 +8795,7 @@ IIO UNIT CONVERTER
> M: Peter Rosin
> L: linux-...@vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
> +F: Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.yaml
> F: Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> F: Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> F: drivers/iio/afe/iio-rescale.c
Re: [PATCH 07/32] MAINTAINERS: update envelope-detector.yaml reference
On Thu, 1 Apr 2021 14:17:27 +0200
Mauro Carvalho Chehab wrote:
> Changeset 66a6dcc20e63 ("dt-bindings:iio:adc:envelope-detector: txt to yaml
> conversion.")
> renamed: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
> to: Documentation/devicetree/bindings/iio/adc/envelope-detector.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 66a6dcc20e63 ("dt-bindings:iio:adc:envelope-detector: txt to yaml
> conversion.")
> Signed-off-by: Mauro Carvalho Chehab
Applied.
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 52ce258fab37..82220a72eba2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8761,7 +8761,7 @@ M: Peter Rosin
> L: linux-...@vger.kernel.org
> S: Maintained
> F: Documentation/ABI/testing/sysfs-bus-iio-adc-envelope-detector
> -F: Documentation/devicetree/bindings/iio/adc/envelope-detector.txt
> +F: Documentation/devicetree/bindings/iio/adc/envelope-detector.yaml
> F: drivers/iio/adc/envelope-detector.c
>
> IIO MULTIPLEXER
Re: [PATCH 06/32] MAINTAINERS: update dpot-dac.yaml reference
On Thu, 1 Apr 2021 14:17:26 +0200
Mauro Carvalho Chehab wrote:
> Changeset 06d2ff6fe11e ("dt-bindings:iio:dac:dpot-dac: yaml conversion.")
> renamed: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
> to: Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 06d2ff6fe11e ("dt-bindings:iio:dac:dpot-dac: yaml conversion.")
> Signed-off-by: Mauro Carvalho Chehab
Applied.
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1985d75d59c7..52ce258fab37 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8753,7 +8753,7 @@ M: Peter Rosin
> L: linux-...@vger.kernel.org
> S: Maintained
> F: Documentation/ABI/testing/sysfs-bus-iio-dac-dpot-dac
> -F: Documentation/devicetree/bindings/iio/dac/dpot-dac.txt
> +F: Documentation/devicetree/bindings/iio/dac/dpot-dac.yaml
> F: drivers/iio/dac/dpot-dac.c
>
> IIO ENVELOPE DETECTOR
Re: [PATCH 05/32] MAINTAINERS: update st,hts221.yaml reference
On Thu, 1 Apr 2021 14:17:25 +0200
Mauro Carvalho Chehab wrote:
> Changeset 9a6ac3138258 ("dt-bindings:iio:humidity:st,hts221 yaml conversion.")
> renamed: Documentation/devicetree/bindings/iio/humidity/hts221.txt
> to: Documentation/devicetree/bindings/iio/humidity/st,hts221.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 9a6ac3138258 ("dt-bindings:iio:humidity:st,hts221 yaml conversion.")
> Signed-off-by: Mauro Carvalho Chehab
Applied
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index de9637196526..1985d75d59c7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8287,7 +8287,7 @@ M: Lorenzo Bianconi
> L: linux-...@vger.kernel.org
> S: Maintained
> W: http://www.st.com/
> -F: Documentation/devicetree/bindings/iio/humidity/hts221.txt
> +F: Documentation/devicetree/bindings/iio/humidity/st,hts221.yaml
> F: drivers/iio/humidity/hts221*
>
> HUAWEI ETHERNET DRIVER
Re: [PATCH 01/32] MAINTAINERS: update adi,ad5758.yaml reference
On Thu, 1 Apr 2021 14:17:21 +0200
Mauro Carvalho Chehab wrote:
> Changeset 1e6536ee349b ("dt-bindings:iio:dac:adi,ad5758 yaml conversion")
> renamed: Documentation/devicetree/bindings/iio/dac/ad5758.txt
> to: Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 1e6536ee349b ("dt-bindings:iio:dac:adi,ad5758 yaml conversion")
> Signed-off-by: Mauro Carvalho Chehab
Hi Mauro,
Oops. These have been on my todo list for a while to tidy up. I kind
of forgot to check MAINTAINERS whilst doing the conversions.
Ah well, thanks for tidying up.
Applied to the togreg branch of iio.git and pushed out as testing for
autobuilders to probably not notice.
Thanks
Jonathan
p.s. For anything IIO related I'll notice more quickly in general
if linux-...@vger.kernel.org is cc'd.
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 38d823d72e52..4c8a926ef201 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1141,7 +1141,7 @@ W:
> http://ez.analog.com/community/linux-device-drivers
> F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523
> F: Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
> F: Documentation/devicetree/bindings/iio/*/adi,*
> -F: Documentation/devicetree/bindings/iio/dac/ad5758.txt
> +F: Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
> F: drivers/iio/*/ad*
> F: drivers/iio/adc/ltc249*
> F: drivers/iio/amplifiers/hmc425a.c
Re: [PATCH] iio: adc: bcm_iproc_adc: Use %s and __func__
On Thu, 1 Apr 2021 20:22:47 +0530
Mugilraj D wrote:
> On 01/04/21 4:00 pm, Jonathan Cameron wrote:
> > On Thu, 1 Apr 2021 12:24:50 +0300
> > Andy Shevchenko wrote:
> >
> >> On Thu, Apr 1, 2021 at 9:27 AM Mugilraj Dhavachelvan
> >> wrote:
> >>>
> >>> Change function's name to %s and __func__ to fix checkpatch.pl errors.
> >>
> >> No, just drop the __func__ completely. First of all, we have a device
> >> name, and uniqueness of the messages in the driver should guarantee
> >> easy findings. Second, specific to _dbg() variants, with enabled
> >> Dynamic Debug it can be chosen at run time!
> >>
> >> I recommend going through all drivers and drop __func__ near to
> >> dev_dbg() and pr_debug().
> >>
> >
> > Agreed. Though beware that some maintainers will count this
> > as noise and get grumpy.
> >
> > I'm fine with such patches for IIO.
>
> Sorry for the noise. I just seen the docs about dynamic debug.
> So, if we use dev_dbg("log_msg") it will print statement like
> filename:lineno [module]func flag log_msg, If I get it correctly.
> And no need of specifying __func__ in dev_dbg() and dp_dbg() right!!
>
> Jonathan do you have any TODO's?
I tend not to mind cleanup patches (within reason)in IIO so I'm absolutely
fine with a series removing any __func__ items like this. One patch per
driver preferred because it avoids issues with this interfering with backports
etc. There will end up being about 18 patches from a quick grep. Perhaps send
a small number first though to avoid having to put in too much effort as
any issues likely to affect the whole set.
Just be careful with other maintainers, they sometimes strike a different
balance for what they consider noise vs useful.
Jonathan
>
> >
> > Jonathan
> >
Re: [PATCH v2 1/5] iio: Documentation: update definitions for bufferY and scan_elements
On Thu, 1 Apr 2021 15:44:08 +0200 Mauro Carvalho Chehab wrote: > Em Wed, 17 Feb 2021 10:34:34 +0200 > Alexandru Ardelean escreveu: > > > Since the new change to the IIO buffer infrastructure, the buffer/ and > > scan_elements/ directories have been merged into bufferY/ to have some > > attributes available per-buffer. > > > > This change updates the ABI docs to reflect this change. > > > > The hwfifo attributes are not updated, as for now these should be used > > via the legacy buffer/ directory until they are moved into core. > > > > Signed-off-by: Alexandru Ardelean > > --- > > Documentation/ABI/testing/sysfs-bus-iio | 85 + > > 1 file changed, 85 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio > > b/Documentation/ABI/testing/sysfs-bus-iio > > index d957f5da5c04..f2a72d7fbacb 100644 > > --- a/Documentation/ABI/testing/sysfs-bus-iio > > +++ b/Documentation/ABI/testing/sysfs-bus-iio > > @@ -1118,12 +1118,16 @@ Description: > > > > What: /sys/bus/iio/devices/iio:deviceX/buffer/length > > KernelVersion: 2.6.35 > > +What: /sys/bus/iio/devices/iio:deviceX/bufferY/length > > +KernelVersion: 5.11 > > Contact: linux-...@vger.kernel.org > > Description: > > Number of scans contained by the buffer. > > The ABI parser doesn't like things like this: > > $ ./scripts/get_abi.pl validate > > Warning: file Documentation/ABI/testing/sysfs-bus-iio#1167: > What '/sys/bus/iio/devices/iio:deviceX/buffer/length' doesn't > have a description > > The main reason is that all properties, including KernelVersion, > Contact and Description are associated to a group of properties. > > To be frank, for me that don't work with IIO, the above ABI > description doesn't sound clear. > > I mean, what's the difference between > /sys/bus/iio/devices/iio:deviceX/buffer/length > and > /sys/bus/iio/devices/iio:deviceX/bufferY/length? > > > If the intention is to tell that: > /sys/bus/iio/devices/iio:deviceX/buffer/length > was obsoleted by: > /sys/bus/iio/devices/iio:deviceX/bufferY/length > > IMO, the right thing would be to move the deprecated definition to > Documentation/ABI/obsolete/ > > If, on the other hand, both are completely identical and > non-obsoleted, why to have both APIs? > > Or did you just missed adding a different description for the > new ABI symbols, but this was dropped due to some merge > conflict? You are right that the version with out the index is obsolete but it's only just become so and there are no realistic way we are going to ever be able to remove it however much we encourage userspace to use the new interface. We are stuck with this bit of backwards compatibility indefinitely. I'm fine with moving it and related definitions over to ABI/obsolete if that makes sense. Jonathan > > Thanks, > Mauro
