> On Mar 30, 2021, at 12:12 PM, Dave Hansen wrote:
>
> On 3/30/21 10:56 AM, Len Brown wrote:
>> On Tue, Mar 30, 2021 at 1:06 PM Andy Lutomirski wrote:
>>>> On Mar 30, 2021, at 10:01 AM, Len Brown wrote:
>>>> Is it required (by the "ABI") tha
Assigning bitmaps like it's done in the driver might be error prone.
Fix this by using bitmap API.
Signed-off-by: Andy Shevchenko
Acked-by: Peter Rosin
---
v2: left blank line untouched (Peter)
drivers/mux/gpio.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers
Module doesn't use OF APIs anyhow, make it OF independent by replacing
headers and dropping useless of_match_ptr() call.
Signed-off-by: Andy Shevchenko
Acked-by: Peter Rosin
---
v2: moved mod_devicetable before module (Peter)
drivers/mux/gpio.c | 4 ++--
1 file changed, 2 insertions(+), 2
Use already prepared dev_err_probe() introduced by the commit
a787e5400a1c ("driver core: add device probe log helper").
It simplifies EPROBE_DEFER handling.
Signed-off-by: Andy Shevchenko
Acked-by: Peter Rosin
---
v2: wrapped to 80 characters (Peter)
drivers/mux/gpio.c | 9 +++
Instead of home grown analogue, use strstrip() from the kernel library.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_si_hotmod.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_hotmod.c
b/drivers/char/ipmi
Instead of twice repeat the constant literals, introduce
panic_event_str array. It allows to simplify the code with
help of match_string() API.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_msghandler.c | 49 ++---
1 file changed, 17 insertions(+), 32
By one of the previous clean up change we got a temporary variable to hold
a device pointer. It can be utilized in other calls in the ->probe() and
save a bit of LOCs.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_si_platform.c | 15 +++
1 file changed, 7 inserti
The ->addr_source_cleanup() callback is solely used by PCI driver
and only for one purpose, i.e. to disable device. Get rid of
->addr_source_cleanup() by switching to PCI managed API.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_si.h | 2 --
drivers/char/ipmi/ipmi_si_
Instead of making the comparison one by one, reuse si_to_str array
in ipmi_hardcode_init_one() in conjunction with match_string() API.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_si.h | 3 +++
drivers/char/ipmi/ipmi_si_hardcode.c | 23 +--
drivers
For easy grepping on debug purposes join string literals back in
the messages.
No functional change.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_msghandler.c | 3 +-
drivers/char/ipmi/ipmi_si_hardcode.c | 50 +---
drivers/char/ipmi/ipmi_si_hotmod.c
Instead of direct comparison, use proper ACPI macros to check error code
for failures.
While at it, drop unneeded 'else' keyword.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_si_platform.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers
There is no more 'free' in the error path, so drop the label and
return errors inline.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_si_platform.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_platform.c
b/drivers
put_device() is NULL aware, drop redundant check before calling it.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_si_hotmod.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_hotmod.c
b/drivers/char/ipmi/ipmi_si_hotmod.c
index
Switch to use new platform_get_mem_or_io() instead of home grown analogue.
Note, we also introduce ipmi_set_addr_data_and_space() helper here.
Signed-off-by: Andy Shevchenko
---
drivers/char/ipmi/ipmi_si_platform.c | 40 +++-
1 file changed, 16 insertions(+), 24
> On Mar 30, 2021, at 10:01 AM, Len Brown wrote:
>
> Andy,
>
> I agree, completely, with your description of the challenge,
> thank you for focusing the discussion on that problem statement.
>
> Question:
>
> Is it required (by the "ABI") that a us
the IMR registers may not match the reversed order in the other
> registers (DCBA, and BA-DC or DC-BA).
Thanks for an update. Much better now!
My comments below.
After addressing them,
Reviewed-by: Andy Shevchenko
>
> Signed-off-by: Sander Vanheule
> Reviewed-by: Linus Walleij
>
> On Mar 30, 2021, at 8:14 AM, Sean Christopherson wrote:
>
> On Mon, Mar 29, 2021, Andy Lutomirski wrote:
>>
>>>> On Mar 29, 2021, at 7:04 PM, Andi Kleen wrote:
>>>
>>>
>>>>
>>>>> No, if these instructions take
Use generic i2c_freq_mode_string() helper to print chosen bus speed.
Signed-off-by: Andy Shevchenko
---
Depends on the "Add support for HiSilicon I2C controller" series.
Message-Id - 1617109549-4013-1-git-send-email-yangyic...@hisilicon.com
Yicong, feel free to attach to your n
On Tue, Mar 30, 2021 at 3:35 PM Henning Schild
wrote:
> Am Tue, 30 Mar 2021 15:15:16 +0300
> schrieb Andy Shevchenko :
> > On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
> > wrote:
> > > Am Tue, 30 Mar 2021 14:04:35 +0300
> > > schrieb Andy Shevchenko :
>
On Tue, Mar 30, 2021 at 2:58 PM Henning Schild
wrote:
> Am Tue, 30 Mar 2021 14:04:35 +0300
> schrieb Andy Shevchenko :
> > On Mon, Mar 29, 2021 at 8:59 PM Henning Schild
> > wrote:
> > >
> > > This driver adds initial support for several devices from Siem
On Tue, Mar 30, 2021 at 3:06 PM Vaittinen, Matti
wrote:
> On Tue, 2021-03-30 at 13:11 +0300, Andy Shevchenko wrote:
> > On Mon, Mar 29, 2021 at 3:58 PM Matti Vaittinen
> > wrote:
> > >
> > > +struct bd71815_gpio {
> > > + struct gpio_c
00 + 0x1D0, "green:" LED_FUNCTION_STATUS "-2"},
> + {0x500 + 0x1E0, "red:" LED_FUNCTION_STATUS "-3"},
> + {0x500 + 0x198, "green:" LED_FUNCTION_STATUS "-3"},
> + { }
> +};
It seems to me like poking GPIO controller registers directly. This is not good.
The question still remains: Can we simply register a GPIO (pin
control) driver and use an LED GPIO driver with an additional board
file that instantiates it?
--
With Best Regards,
Andy Shevchenko
ning: cast from pointer to
> integer of different size [-Wpointer-to-int-cast]
> 503 |(uint32_t) desc->drv_data, 0);
> |^
>
> Modify the code to make it similar to bcm63268_set_gpio() in order to fix
> the warning.
Seems good to me, thanks!
Re
On Tue, Mar 30, 2021 at 1:43 PM Matti Vaittinen
wrote:
> On Tue, 2021-03-30 at 13:11 +0300, Andy Shevchenko wrote:
...
> Andy, how fatal do you think these issues are? I did put these comments
> on my 'things to clean-up' list.
>
> If you don't see them as fatal, then I rather n
evel:
> + "L" - low; "H" - high; "R" - rising; "F" - falling
> +Examples:
> +Samples $NUMSAMPLES at 1MHz with already prepared CPU or automatically
> prepare CPU1 if needed
with an already
prepares
> + '$0'
> +Samples 50us at 2MHz waiting for falling edge on channel 2. CPU usage as
> above.
> + '$0 -d 50 -s 200 -t "2F"'
> +
> +Note that the process exits after checking all parameters but a sub-process
> still works in
> +the background. The result is only available once the sub-process finished.
> As the time of
finishes
> +writing, the sub-process is not killable, so be extra careful that your
> triggers work.
> +
> +Result is a .sr file to be consumed with PulseView from the free Sigrok
> project. It is
> +a zip file which also contains the binary sample data which may be consumed
> by others.
> +The filename is the logic analyzer instance name plus a since-epoch
> timestamp.
> +EOF
> +}
--
With Best Regards,
Andy Shevchenko
ts(pc->regs, BCM6362_BASEMODE_REG, basemode,
> + 0);
Put it on one line for sake of the readability.
>
> if (pin < BCM63XX_BANK_GPIOS) {
> /* base mode 0 => gpio 1 => mux function */
> --
> 2.20.1
>
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 30, 2021 at 7:32 AM Matti Vaittinen
wrote:
> On Mon, 2021-03-29 at 16:30 +0300, Andy Shevchenko wrote:
> > On Mon, Mar 29, 2021 at 03:20:07PM +0300, Matti Vaittinen wrote:
...
> > I think the error code which is Linux kernel internal is for a
> > reason.
>
On Mon, Mar 29, 2021 at 8:28 PM Sander Vanheule wrote:
> On Mon, 2021-03-29 at 13:26 +0300, Andy Shevchenko wrote:
> > On Fri, Mar 26, 2021 at 11:11 PM Sander Vanheule <
> > san...@svanheule.net> wrote:
...
> > AFAICS all, except one have this flag, I suggest you to d
;
> + }
> +
> + return ret;
This entire piece can be simplified by
return devm_gpiochip_add_data(...);
...
> +static struct platform_driver gpo_bd71815_driver = {
> + .driver = {
> + .name = "bd71815-gpo",
> + .owner
r and this should be
deduplicated on how they instantiate a USB PD slave device.
> +static int navi_amd_register_client(struct dw_i2c_dev *dev)
> +{
> + struct i2c_board_info info;
> +
> + memset(, 0, sizeof(struct i2c_board_info));
> + strscpy(info.type, "ccgx-ucsi", I2C_NAME_SIZE);
> + info.addr = 0x08;
> + info.irq = dev->irq;
> +
> + dev->slave = i2c_new_client_device(>adapter, );
> + if (!dev->slave)
> + return -ENODEV;
> +
> + return 0;
> +}
...
> + if (dev->flags & MODEL_AMD_NAVI_GPU)
> + r = navi_amd_register_client(dev);
> + if (r) {
> + dev_err(dev->dev, "register client failed with %d\n", r);
> + return r;
> + }
This seems to be on a wrong scope.
--
With Best Regards,
Andy Shevchenko
e you fix, but I
suggest to switch to devm*, pcim* APIs instead,
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 29, 2021 at 11:45:29PM +0100, Daniel Scally wrote:
> On 29/03/2021 16:12, Andy Shevchenko wrote:
> > This is useful to assign software node reference with arguments
> > in a common way. Moreover, we have already couple of users that
> > may be converted. And by
On Mon, Mar 29, 2021 at 3:38 PM Len Brown wrote:
>
> On Mon, Mar 29, 2021 at 2:16 PM Andy Lutomirski wrote:
> >
> Hi Andy,
>
> Can you provide a concise definition of the exact problemI(s) this thread
> is attempting to address?
The AVX-512 state, all by itself,
> On Mar 29, 2021, at 7:04 PM, Andi Kleen wrote:
>
>
>>
>>> No, if these instructions take a #VE then they were executed at CPL=0.
>>> MONITOR
>>> and MWAIT will #UD without VM-Exit->#VE. Same for WBINVD, s/#UD/#GP.
>>
>> Dare I ask about XSETBV?
>
> XGETBV does not cause a #VE, it
On Mon, Mar 29, 2021 at 4:42 PM Sean Christopherson wrote:
>
> On Mon, Mar 29, 2021, Kuppuswamy, Sathyanarayanan wrote:
> >
> >
> > On 3/29/21 4:23 PM, Andy Lutomirski wrote:
> > >
> > > > On Mar 29, 2021, at 4:17 PM, Kuppuswamy Sathyanarayanan
>
> On Mar 29, 2021, at 2:55 PM, Marco Elver wrote:
>
> On Mon, 29 Mar 2021 at 23:47, Andy Lutomirski wrote:
>>
>>
>>>> On Mar 29, 2021, at 2:34 PM, Marco Elver wrote:
>>>
>>> On Mon, 29 Mar 2021 at 23:03, Dave Hansen wrote:
>>>
> On Mar 29, 2021, at 4:17 PM, Kuppuswamy Sathyanarayanan
> wrote:
>
> In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
> are not supported. So handle #VE due to these instructions
> appropriately.
Is there something I missed elsewhere in the code that checks CPL?
> On Mar 29, 2021, at 2:34 PM, Marco Elver wrote:
>
> On Mon, 29 Mar 2021 at 23:03, Dave Hansen wrote:
>>> On 3/29/21 10:45 AM, Marco Elver wrote:
On Mon, 29 Mar 2021 at 19:32, Dave Hansen wrote:
>>> Doing it to all CPUs is too expensive, and we can tolerate this being
>>> approximate
> On Mar 29, 2021, at 8:47 AM, Len Brown wrote:
>
> On Sat, Mar 27, 2021 at 5:58 AM Greg KH wrote:
>>> On Fri, Mar 26, 2021 at 11:39:18PM -0400, Len Brown wrote:
>>> Hi Andy,
>>> Say a mainline links with a math library that uses AMX without the
>&
> On Mar 29, 2021, at 9:39 AM, Len Brown wrote:
>
>
>>
>> In particular, the library may use instructions that main() doesn't know
>> exist.
>
> And so I'll ask my question another way.
>
> How is it okay to change the value of XCR0 during the run time of a program?
>
> I submit that
> On Mar 29, 2021, at 9:06 AM, Len Brown wrote:
>
> On Mon, Mar 29, 2021 at 11:43 AM Len Brown wrote:
>>
>> On Mon, Mar 29, 2021 at 9:33 AM Thomas Gleixner wrote:
>>
I found the author of this passage, and he agreed to revise it to say this
was targeted primarily at VMMs.
>>>
On Mon, Mar 29, 2021 at 08:08:52AM -0700, Joe Perches wrote:
> On Mon, 2021-03-29 at 14:59 +0300, Andy Shevchenko wrote:
> > On Mon, Mar 29, 2021 at 2:43 PM Matti Vaittinen
> > wrote:
> > >
> > > The checkpacth instructs to switch from ENOSUPP to EOPN
a const, while the data underneath
can be modified?
> + unsigned int *const width = chip->gpio_width;
Ditto.
Putting const:s here and there for sake of the const is not good practice.
It makes code harder to read.
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 29, 2021 at 6:15 PM Andy Shevchenko
wrote:
>
> On Wed, Mar 17, 2021 at 06:39:00AM +, LI Qingwu wrote:
> > Changes in V3:
>
> Jonathan, is this applied? I missed it...
I found the reply, sorry for a noise.
--
With Best Regards,
Andy Shevchenko
On Wed, Mar 17, 2021 at 06:39:00AM +, LI Qingwu wrote:
> Changes in V3:
Jonathan, is this applied? I missed it...
--
With Best Regards,
Andy Shevchenko
On Thu, Mar 25, 2021 at 07:34:07PM +0200, Andy Shevchenko wrote:
> The series provides one fix (patch 1) for GPIO to be able to wait for
> the GPIO driver to appear. This is separated from the conversion to
> the GPIO descriptors (patch 2) in order to have a possibility for
> backport
This is useful to assign software node reference with arguments
in a common way. Moreover, we have already couple of users that
may be converted. And by the fact, one of them is moved right here
to use the helper.
Signed-off-by: Andy Shevchenko
---
v2: no changes
drivers/base/test/property
Introduce software_node_alloc() and software_node_free() helpers.
This will help with code readability and maintenance.
Signed-off-by: Andy Shevchenko
---
v2: no changes
drivers/base/swnode.c | 47 ++-
1 file changed, 24 insertions(+), 23 deletions
/-100 (-91)
Total: Before=7217, After=7126, chg -1.26%
Signed-off-by: Andy Shevchenko
---
v2: added the object file name against which bloat-o-meter was run (Greg)
drivers/base/swnode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/swnode.c b/drivers/base
This is useful to assign software node reference with arguments
in a common way. Switch to use SOFTWARE_NODE_REFERENCE() here.
Signed-off-by: Andy Shevchenko
---
v2: no changes
drivers/media/pci/intel/ipu3/cio2-bridge.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Deduplicate conditional and assignment in fwnode_create_software_node(),
i.e. parent is checked in two out of three cases and parent software node
is assigned by to_swnode() call.
Signed-off-by: Andy Shevchenko
---
v2: no changes
drivers/base/swnode.c | 17 -
1 file changed, 8
nly in fwnode_create_software_node().
Signed-off-by: Andy Shevchenko
---
v2: no changes
drivers/base/swnode.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index fa3719ef80e4..456f5fe58b58 100
Since there have already been a whole
> > bunch of review-comments, I've not taken a detailed look at this yet.
>
> No problem, I'm hoping to do a v3 over the weekend anyway.
Do you mean v4?
I'm just wondering if you need any help.
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 29, 2021 at 4:46 PM Greg Kroah-Hartman
wrote:
> On Mon, Mar 29, 2021 at 04:01:18PM +0300, Andy Shevchenko wrote:
> > On Sun, Mar 28, 2021 at 03:02:24PM +0200, Greg Kroah-Hartman wrote:
> > > On Sun, Mar 28, 2021 at 03:56:26PM +0300, Andy Shevchenko wrote:
> >
ul conversion.
>
> Note that where a very large number is used to mean "unlimited", the value
> INT_MAX is used for consistency with the behaviour of vsnprintf().
...
> unsigned long simple_strtoul(const char *cp, char **endp, unsigned int base)
> {
> - return simple_strtoull(cp, endp, base);
> + return simple_strntoull(cp, INT_MAX, endp, base);
Why do you need this change?
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 29, 2021 at 03:20:07PM +0300, Matti Vaittinen wrote:
> On Mon, 2021-03-29 at 14:59 +0300, Andy Shevchenko wrote:
> > On Mon, Mar 29, 2021 at 2:43 PM Matti Vaittinen
> > wrote:
> > > The checkpacth instructs to switch from ENOSUPP to EOPNOTSUPP.
> > > &
On Sun, Mar 28, 2021 at 03:02:24PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Mar 28, 2021 at 03:56:26PM +0300, Andy Shevchenko wrote:
> > On Sun, Mar 28, 2021 at 9:47 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Sun, Mar 28, 2021 at 12:20:07AM +0200, Andy Sh
On Fri, Mar 26, 2021 at 07:23:59PM +0200, Andy Shevchenko wrote:
> Assigning bitmaps like it's done in the driver might be error prone.
> Fix this by using bitmap API.
Peter, are you okay with the patches?
Should I reroute them to Greg?
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 29, 2021 at 11:25:58AM +0530, Goswami, Sanket wrote:
> On 26-Mar-21 16:10, Andy Shevchenko wrote:
> > On Fri, Mar 26, 2021 at 03:53:34PM +0530, Goswami, Sanket wrote:
> >> On 25-Mar-21 22:35, Andy Shevchenko wrote:
> >>> On Mon, Mar 22, 2021 at 10:26:55P
one of the checkpatch complaints.
Internally we are fine to use the ENOTSUPP.
Checkpatch false positives there.
I doubt we need this change. Rather checkpatch should rephrase this to
point out that this is only applicable to _user-visible_ error path.
Cc'ed Joe.
--
With Best Regards,
Andy Shevchenko
if you can convert those pr_*() to dev_*(), but it's definitely
out of the scope here.
I like the idea, FWIW,
Reviewed-by: Andy Shevchenko
> ---
> drivers/gpio/gpiolib-sysfs.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib-sysfs.c b/dri
On Mon, Mar 29, 2021 at 2:49 PM zhiyong tao wrote:
> On Mon, 2021-03-29 at 14:35 +0300, Andy Shevchenko wrote:
> > On Mon, Mar 29, 2021 at 2:32 PM Zhiyong Tao
> > wrote:
> > >
> > > This series includes 6 patches:
> > > 1.add pinctrl file on mt
ns on MT8195.
> 6.add pinctrl rsel setting on MT8195.
Patch series w/o version is de facto v1.
Dropping to v0 seems not right.
You missed changelog.
So, send v2 properly.
Material to study:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
--
With Best Regards,
Andy Shevchenko
> + #include
> #include
> +#include
> +
> +struct device;
>
> /*
>* bitmaps provide bit arrays that consume one or more unsigned
--
With Best Regards,
Andy Shevchenko
e to add for sake of the clarification that we are trying really
hard to make drivers agnostic to the device tree provider. In such a
case the same driver can work for all existing providers (ACPI, DT,
and board files with use of software nodes).
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 29, 2021 at 12:58 AM Willy Tarreau wrote:
>
> On Sun, Mar 28, 2021 at 11:14:05PM +0300, Andy Shevchenko wrote:
> > On Sunday, March 28, 2021, Willy Tarreau wrote:
> >
> > > Hi Thomas,
> > >
> > > On Sun, Mar 28, 2021 at 03:07:24AM +0200,
+Cc: Hans (just for your opinion)
On Sun, Mar 28, 2021 at 10:40 PM Andy Shevchenko
wrote:
> On Sunday, March 28, 2021, Mugilraj Dhavachelvan wrote:
>>
>> As per linux kernel coding style braces are not needed for single
>> statement.
>> Checkpatch
>> warning: br
d pins on MT8195.
> 6.add pinctrl rsel setting on MT8195.
You submitted the same version of the series twice, but it confuses people.
Now you have to properly send the series only one time with the
correct version added and changelog explains the changes done between
the versions.
--
With Best Regards,
Andy Shevchenko
a driver for that in
the kernel?
--
With Best Regards,
Andy Shevchenko
dws, DW_SPI_SER, 0);
> + }
> +}
--
With Best Regards,
Andy Shevchenko
ENSE("GPL v2");
> +MODULE_DESCRIPTION("Pensando Elba SoC SPI chip-select driver");
It's funny, you told it can't be a module and you add a dead code. Be
somehow consistent, please.
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 29, 2021 at 4:19 AM Brad Larson wrote:
> On Sun, Mar 7, 2021 at 11:21 AM Andy Shevchenko
> wrote:
> > On Thu, Mar 4, 2021 at 4:40 PM Brad Larson wrote:
...
> > > +config GPIO_ELBA_SPICS
> > > + bool "Pensando Elba SPI chip-select"
&g
On Fri, Mar 26, 2021 at 11:11 PM Sander Vanheule wrote:
> On Fri, 2021-03-26 at 20:19 +0200, Andy Shevchenko wrote:
> > On Fri, Mar 26, 2021 at 2:05 PM Sander Vanheule
> > wrote:
...
> > > + bool "Realtek Otto GPIO support"
> >
> > Why not m
On Sun, Mar 28, 2021 at 9:47 AM Greg Kroah-Hartman
wrote:
>
> On Sun, Mar 28, 2021 at 12:20:07AM +0200, Andy Shevchenko wrote:
> > It's very convenient to see what properties and their values
> > are currently being assigned in the registered software nodes.
>
On Sun, Mar 28, 2021 at 11:47 AM Greg Kroah-Hartman
wrote:
>
> On Sun, Mar 28, 2021 at 12:20:09AM +0200, Andy Shevchenko wrote:
> > Since we don't use structure field layout randomization
> > the manual shuffling can affect some macros, in particular
> > kobj_to_swnode(
On Sun, Mar 28, 2021 at 11:48 AM Greg Kroah-Hartman
wrote:
>
> On Sun, Mar 28, 2021 at 12:20:10AM +0200, Andy Shevchenko wrote:
> > By introducing two temporary variables simplify swnode_register() a bit.
> > No functional change intended.
> >
> >
On Sun, Mar 28, 2021 at 12:23 AM Al Viro wrote:
>
> On Fri, Mar 26, 2021 at 07:03:47PM +0200, Andy Shevchenko wrote:
> > The bitmap.h header is used in a lot of code around the kernel.
> > Besides that it includes kernel.h which sometimes makes a loop.
>
> How much of the
This is useful to assign software node reference with arguments
in a common way. Moreover, we have already couple of users that
may be converted. And by the fact, one of them is moved right here
to use the helper.
Signed-off-by: Andy Shevchenko
---
drivers/base/test/property-entry-test.c | 11
)
Total: Before=7217, After=7126, chg -1.26%
Signed-off-by: Andy Shevchenko
---
drivers/base/swnode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 22f81688af2c..ae53c48f84b1 100644
--- a/drivers/base/swnode.c
+++ b/drivers
It's very convenient to see what properties and their values
are currently being assigned in the registered software nodes.
Show properties and their values in sysfs.
Signed-off-by: Andy Shevchenko
---
drivers/base/swnode.c | 137 --
1 file changed, 132
By introducing two temporary variables simplify swnode_register() a bit.
No functional change intended.
Signed-off-by: Andy Shevchenko
---
drivers/base/swnode.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index
This is useful to assign software node reference with arguments
in a common way. Switch to use SOFTWARE_NODE_REFERENCE() here.
Signed-off-by: Andy Shevchenko
---
drivers/media/pci/intel/ipu3/cio2-bridge.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci
nly in fwnode_create_software_node().
Signed-off-by: Andy Shevchenko
---
drivers/base/swnode.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index fa3719ef80e4..456f5fe58b58 100644
--- a/drivers/b
Deduplicate conditional and assignment in fwnode_create_software_node(),
i.e. parent is checked in two out of three cases and parent software node
is assigned by to_swnode() call.
Signed-off-by: Andy Shevchenko
---
drivers/base/swnode.c | 17 -
1 file changed, 8 insertions(+), 9
Introduce software_node_alloc() and software_node_free() helpers.
This will help with code readability and maintenance.
Signed-off-by: Andy Shevchenko
---
drivers/base/swnode.c | 47 ++-
1 file changed, 24 insertions(+), 23 deletions(-)
diff --git
On Sat, Mar 27, 2021 at 8:18 PM Daniel Gomez wrote:
> On Fri, 26 Mar 2021 at 13:28, Andy Shevchenko
> wrote:
> > On Fri, Mar 26, 2021 at 11:35:08AM +0100, Daniel Gomez wrote:
...
> > It's a good question. On one hand we know that resource_size_t is a simple
> > red
On Sat, Mar 27, 2021 at 3:39 PM Joe Perches wrote:
>
> On Sat, 2021-03-27 at 10:19 +0200, Andy Shevchenko wrote:
> > On Saturday, March 27, 2021, Xiaofei Tan wrote:
> >
> > > Fix some coding style issues reported by checkpatch.pl, including
> > >
On Sat, Mar 27, 2021 at 2:02 PM William Breathitt Gray
wrote:
> On Sat, Mar 27, 2021 at 09:29:26AM +0200, Andy Shevchenko wrote:
> > On Saturday, March 27, 2021, Syed Nayyar Waris wrote:
> > > On Fri, Mar 26, 2021 at 11:32 PM Andy Shevchenko
> > > wrote:
> > &
> On Mar 26, 2021, at 8:40 PM, Kuppuswamy, Sathyanarayanan
> wrote:
>
>
>
> On 3/26/21 7:40 PM, Andy Lutomirski wrote:
>>>> On Mar 26, 2021, at 5:18 PM, Kuppuswamy Sathyanarayanan
>>>> wrote:
>>>
>>> In non
> On Mar 26, 2021, at 5:18 PM, Kuppuswamy Sathyanarayanan
> wrote:
>
> In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
> are not supported. So handle #VE due to these instructions as no ops.
These should at least be WARN.
Does TDX send #UD if these instructions have the
Sigh, cc linux-api, not linux-abi.
On Fri, Mar 26, 2021 at 4:12 PM Andy Lutomirski wrote:
>
> Hi all-
>
> After some discussion on IRC, I have a proposal for a Linux ABI for
> using Intel AMX and other similar features. It works like this:
>
> First, we make XCR0 dynamic.
lots of programs, following
POSIX (!), seem to think that they know much much space to allocate
for sigaltstack(). AVX-512 is too big.
Thoughts?
--Andy
do on broken devices that do change their state based on that
bit while violating specification).
In any case
Acked-by: Andy Shevchenko
for DesignWare DMA case. I have added that and I never saw that IP connected
to the old PCI.
--
With Best Regards,
Andy Shevchenko
> On Mar 26, 2021, at 2:11 PM, Florian Weimer wrote:
>
> * Andy Lutomirski:
>
>>> On Fri, Mar 26, 2021 at 1:35 PM Florian Weimer wrote:
>>>
>>> I mean the immense slowdown you get if you use %xmm registers after
> their %ymm counterparts (doesn'
On Fri, Mar 26, 2021 at 1:35 PM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> > On Fri, Mar 26, 2021 at 12:34 PM Florian Weimer wrote:
> >> x86: Sporadic failures in tst-cpu-features-cpuinfo
> >> <https://sourceware.org/bugzilla/show_bug.cgi?id
On Fri, Mar 26, 2021 at 12:34 PM Florian Weimer wrote:
>
> * Andy Lutomirski:
>
> >> > AVX-512 cleared, and programs need to explicitly request enablement.
> >> > This would allow programs to opt into not saving/restoring across
> >> > signal
gt; +
Extra blank line.
> +MODULE_DEVICE_TABLE(of, realtek_gpio_of_match);
...
> + iowrite32(GENMASK(31, 0), ctrl->base + REALTEK_GPIO_REG_ISR);
This one perhaps needs a comment like "cleaning all IRQ states".
Note, we have a proper callback for this, i.e. hw_init. Consider to use it.
...
> +};
> +
Extra blank line.
> +builtin_platform_driver(realtek_gpio_driver);
...
So, looking into the code, I think you may easily get rid of 30-50 LOCs.
So, expecting <= 300 LOCs in v5.
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 26, 2021 at 3:08 AM Borislav Petkov wrote:
>
> On Thu, Mar 25, 2021 at 09:38:24PM -0700, Andy Lutomirski wrote:
> > I think we should seriously consider solutions in which, for new
> > tasks, XCR0 has new giant features (e.g. AMX) and possibly even
> > AVX-5
On Fri, Mar 26, 2021 at 5:12 AM Florian Weimer wrote:
>
> * Andy Lutomirski-alpha:
>
> > glibc appears to use AVX512F for memcpy by default. (Unless
> > Prefer_ERMS is default-on, but I genuinely can't tell if this is the
> > case. I did some searching.) The commit
On Fri, Mar 26, 2021 at 10:54 AM Len Brown wrote:
>
> On Fri, Mar 26, 2021 at 11:48 AM Andy Lutomirski wrote:
>
> > > I submit, that after the generic XFD support is in place,
> > > there is exactly 1 bit that needs to be flipped to enable
> > > u
401 - 500 of 41493 matches
Mail list logo
