look at it as well.
> Anyway feel free to add Reviewed-by: Christian König
> .
Side note: I don't believe tools support embedded tags, so we usually give
a tag as one tag per one line without. Otherwise it adds a manual job to
harvest them and ensure no typos made during that.
--
With Best Regards,
Andy Shevchenko
ECOVERY_REBIND) etc.), or
> make this a array of structs mapping the macro values to strings and
> loop over it.
>
> Also, the main point of the static assert was to ensure the array is
> updated when a new recovery option is added, and there's no out of
> bounds acces
On Fri, May 31, 2024 at 02:31:45PM -0700, Chia-I Wu wrote:
> On Fri, May 31, 2024 at 1:57 AM Andy Shevchenko <
> andriy.shevche...@linux.intel.com> wrote:
> > On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote:
...
> > P.S> I'm not so sure about this chang
On Sun, Jun 02, 2024 at 05:21:03PM +0300, Andy Shevchenko wrote:
> Compilation fails on arm with:
>
> link_factory.c:743:1: error: the frame size of 1032 bytes is larger than
> 1024 bytes [-Werror=frame-larger-than=]
>
> Fix the frame size by allocation one of the big struc
ata from cpu memory into amdgpu
> bo, the throughput goes from 5.1GB/s to 6.6GB/s. perf report says
Also in the $Subj (and pay attention to the prefix)
"resource: ... find_next_iomem_res()"
--
With Best Regards,
Andy Shevchenko
Compilation fails on arm with:
link_factory.c:743:1: error: the frame size of 1032 bytes is larger than 1024
bytes [-Werror=frame-larger-than=]
Fix the frame size by allocation one of the big structures.
Signed-off-by: Andy Shevchenko
---
.../gpu/drm/amd/display/dc/link/link_factory.c
her way they
needs to be added / expanded).
P.S> I'm not so sure about this change. It needs a thoroughly testing, esp.
in PCI case. Cc'ing to Ilpo.
--
With Best Regards,
Andy Shevchenko
ts MFD
version should be taken).
--
With Best Regards,
Andy Shevchenko
ge for modules, but if you compile in the
linker may try to optimize it. Would be nice to see the old-new for
`make allyesconfig` or equivalent.
...
> seq_printf(m, "\tDP branch device present: %s\n",
> - branch_device ? "yes" : "no");
> + str_yes_no(branch_device));
Can it be now on one line? Same Q for all similar cases in the entire series.
--
With Best Regards,
Andy Shevchenko
11 +-
> drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 +-
> .../ethernet/chelsio/cxgb4/cxgb4_debugfs.c| 249 ++
> include/linux/string_helpers.h| 20 ++
> security/tomoyo/audit.c | 2 +-
> security/tomoyo/common.c | 19 +-
> security/tomoyo/common.h | 1 -
> 60 files changed, 482 insertions(+), 373 deletions(-)
>
> --
> 2.34.1
>
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 26, 2022 at 02:43:45AM -0800, Lucas De Marchi wrote:
> On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
> > wrote:
...
> > > 411986 104906176 428652 68a6c drm.ko.old
> > >
On Wed, Jan 19, 2022 at 04:00:17PM -0500, Steven Rostedt wrote:
> On Wed, 19 Jan 2022 21:25:08 +0200
> Andy Shevchenko wrote:
>
> > > I say keep it one line!
> > >
> > > Reviewed-by: Steven Rostedt (Google)
> >
> > I believe
E.g. yesno() to me doesn't sound too bad to misunderstand its meaning,
esp.when it's used as an argument to the printf() functions.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 19, 2022 at 11:35:22AM +0900, Esaki Tomohito wrote:
> On 2022/01/18 18:53, Andy Shevchenko wrote:
> > On Mon, Jan 17, 2022 at 02:15:48PM +0900, Esaki Tomohito wrote:
> > > On 2022/01/14 23:16, Andy Shevchenko wrote:
> > > > On Fri, Jan 14, 2022 at 07:17:52
o\0\0yes" + v * 4' works a bit better.
Is it a C code obfuscation contest?
--
With Best Regards,
Andy Shevchenko
yesno(ident1 & V3D_HUB_IDENT1_WITH_TSY));
> seq_printf(m, "MSO:%s\n",
> -(ident1 & V3D_HUB_IDENT1_WITH_MSO) ? "yes" : "no");
> +yesno(ident1 & V3D_HUB_IDENT1_WITH_MSO));
> seq_printf(m, "L3C:%s (%dkb)\n",
> -(ident1 & V3D_HUB_IDENT1_WITH_L3C) ? "yes" : "no",
> +yesno(ident1 & V3D_HUB_IDENT1_WITH_L3C),
> V3D_GET_FIELD(ident2, V3D_HUB_IDENT2_L3C_NKB));
I believe it's fine to join back to have less LOCs (yes, it will be 83 or so,
but I believe in these cases it's very much okay).
--
With Best Regards,
Andy Shevchenko
>
> I say keep it one line!
>
> Reviewed-by: Steven Rostedt (Google)
I believe Sakari strongly follows the 80 rule, which means...
> > Reviewed-by: Sakari Ailus
...chose either of these tags and be happy with :-)
--
With Best Regards,
Andy Shevchenko
TLOG_YES));
> +yesno(cond->grant_log ==
> TOMOYO_GRANTLOG_YES));
> tomoyo_set_lf(head);
> return true;
> }
> diff --git a/security/tomoyo/common.h b/security/tomoyo/common.h
> index 85246b9df7ca..ca285f362705 100644
> --- a/security/tomoyo/common.h
> +++ b/security/tomoyo/common.h
> @@ -959,7 +959,6 @@ char *tomoyo_read_token(struct tomoyo_acl_param
> *param);
> char *tomoyo_realpath_from_path(const struct path *path);
> char *tomoyo_realpath_nofollow(const char *pathname);
> const char *tomoyo_get_exe(void);
> -const char *tomoyo_yesno(const unsigned int value);
> const struct tomoyo_path_info *tomoyo_compare_name_union
> (const struct tomoyo_path_info *name, const struct tomoyo_name_union
> *ptr);
> const struct tomoyo_path_info *tomoyo_get_domainname
> --
> 2.34.1
>
>
--
With Best Regards,
Andy Shevchenko
inline const char *enabledisable(bool v) { return v ? "enable" :
> "disable"; }
> +static inline const char *enableddisabled(bool v) { return v ? "enabled"
> : "disabled"; }
Looks not readable even if takes 80 characters. Please, keep original style.
I believe you wanted to have nice negative statistics from day 1, then you
may add more patches in the series to cleanup more users.
>
> #endif
> --
> 2.34.1
>
>
--
With Best Regards,
Andy Shevchenko
red starting with drm/ since this is "closer to home".
>
> I hope this is a good summary of the previous attempts and a way we can
> move forward.
>
> Andrew Morton, Petr Mladek, Andy Shevchenko: if this is accepted, my
> proposal is to take first 2 patches either t
On Mon, Jan 17, 2022 at 02:15:48PM +0900, Esaki Tomohito wrote:
> On 2022/01/14 23:16, Andy Shevchenko wrote:
> > On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
> > > The LINEAR modifier is advertised as default if a driver doesn't
remove the mode_config.allow_fb_modifiers hook and always
> > advertise modifier support, unless
> > mode_config.cannot_support_modifiers is set
FWIW,
Reviewed-by: Andy Shevchenko
> [1]
> https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-e...@ige
On Fri, Jan 14, 2022 at 03:07:21PM +, Simon Ser wrote:
> On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> wrote:
>
> > Why not enum?
>
> There is no enum for DRM format modifiers.
I'm not sure how this prevents to use enum in the code instead of const u6
On Fri, Jan 14, 2022 at 03:42:54PM +, Simon Ser wrote:
> On Friday, January 14th, 2022 at 16:17, Andy Shevchenko
> wrote:
>
> > On Fri, Jan 14, 2022 at 03:07:21PM +, Simon Ser wrote:
> > > On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> > >
MOD_INVALID
+ Comma?
> + };
Why not enum?
--
With Best Regards,
Andy Shevchenko
On Mon, Nov 15, 2021 at 01:43:02PM +0200, Jani Nikula wrote:
> On Mon, 15 Nov 2021, Andy Shevchenko
> wrote:
> > On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> >> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> >>
On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helper
info("query %d: \"%s\" %s\n", i, query, (modname) ?
> modname : "");
too many parentheses. Also may use
modname ?: ""
form (but not all maintainers are happy with it).
...
> + if (!bitmap) {
> + pr_err("set_dyndbg: no bits=>queries map\n");
> + return -EINVAL;
> + }
> + rc = kstrtoul(instr, 0, &inbits);
> + if (rc) {
> + pr_err("set_dyndbg: failed\n");
> + return rc;
> + }
> + vpr_info("set_dyndbg: input 0x%lx\n", inbits);
> +
> + for (i = 0; bitmap->prefix; i++, bitmap++) {
> + snprintf(query, FMT_QUERY_SIZE, "format '^%s' %cp",
> bitmap->prefix,
> +test_bit(i, &inbits) ? '+' : '-');
> +
> + matches = ddebug_exec_queries(query, KP_MOD_NAME);
> +
> + v2pr_info("bit-%d: %d matches on '%s'\n", i, matches, query);
> + totct += matches;
> + }
I'm wondering if there is a room to parse a bitmap as a bitmap.
...
> +int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
> +{
> + return scnprintf(buffer, PAGE_SIZE, "%u\n",
> +*((unsigned int *)kp->arg));
One line?
> +}
--
With Best Regards,
Andy Shevchenko
kp->data;
So you need space after ')' ?
> + rc = kstrtoul(instr, 0, &inbits);
> + if (rc) {
> + pr_err("set_dyndbg: failed\n");
> + return -EINVAL;
Why not to return rc?
> + }
> + vpr_info("set_dyndbg: input 0x%lx\n", inbits);
> +
> + for (i = 0; !!bitmap[i].prefix; i++) {
Hmm... Why not simply
for (bitmap = ...; bitmap->prefix; bitmap++) {
?
> +
Redundant blank line.
> + sprintf(query, "format '^%s' %cp", bitmap[i].prefix,
> + test_bit(i, &inbits) ? '+' : '-');
snprintf() ?
> +
> + chgct = dynamic_debug_exec_queries(query, kp->mod->name);
> +
> + v2pr_info("bit-%d: %d changes by '%s'\n", i, chgct, query);
> + totct += chgct;
> + }
> + vpr_info("total changes: %d\n", totct);
> + return 0;
> +}
...
> + return scnprintf(buffer, PAGE_SIZE, "%u\n",
> + *((unsigned int *)kp->arg));
One line.
--
With Best Regards,
Andy Shevchenko
KERNEL_PARAM_FL_UNSAFE)
(above left for the above comment)
...
> +#define __module_param_call_wdata(prefix, name, ops, arg, perm, level,
> flags, data) \
Similar __module_param_call_with_data()
--
With Best Regards,
Andy Shevchenko
On Mon, Feb 15, 2021 at 04:37:50PM +0200, Jani Nikula wrote:
> On Mon, 15 Feb 2021, Andy Shevchenko
> wrote:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helpers under string.h hood
We have already few similar implementation and a lot of code that can benefit
of the yesno() helper. Consolidate yesno() helpers under string.h hood.
Signed-off-by: Andy Shevchenko
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c| 6 +-
drivers/gpu/drm/i915/i915_utils.h
+Cc: Sakari and printk people
On Mon, Feb 15, 2021 at 4:28 PM Christian König
wrote:
> Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helper
We have already an implementation and a lot of code that can benefit
of the onoff() helper. Move it under string.h hood.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_utils.h | 5 -
include/linux/string.h| 5 +
2 files changed, 5 insertions(+), 5 deletions
We have already an implementation and a lot of code that can benefit
of the enableddisabled() helper. Move it under string.h hood.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_utils.h | 5 -
include/linux/string.h| 5 +
2 files changed, 5 insertions(+), 5
ually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.
--
With Best Regards,
Andy Shevchenko
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Tue, Jun 2, 2020 at 5:21 PM Alex Deucher wrote:
> On Tue, Jun 2, 2020 at 10:00 AM Andy Shevchenko
> wrote:
> > On Tue, Jun 2, 2020 at 4:38 PM Ruhl, Michael J
> > wrote:
> > > >From: dri-devel On Behalf Of
> > > >Piotr Stankiewicz
> > >
gt;
> pci_alloc_irq_vector() tries stuff in order. If MSIX is not available,
> it will try MSI.
That's also what I proposed earlier. But I suggested as well to wait
for AMD people to confirm that neither pci_msix_vec_count() nor flags
is needed and we can directly supply MSI_T
On Tue, Jun 2, 2020 at 12:24 PM Piotr Stankiewicz
wrote:
>
> Seeing as there is shorthand available to use when asking for any type
> of interrupt, or any type of message signalled interrupt, leverage it.
>
> Signed-off-by: Piotr Stankiewicz
> Reviewed-by: Andy Shevchenko
&g
On Tue, Jun 2, 2020 at 12:58 PM Stankiewicz, Piotr
wrote:
> > -Original Message-
> > From: Andy Shevchenko
> > Sent: Tuesday, June 2, 2020 11:49 AM
> > To: Stankiewicz, Piotr
> > Cc: Alex Deucher ; Christian König
> > ; David Zhou ; David
>
E conversion.
> I'll post the patches I made for that later, as they need more
> testing and review from the scsi maintainers.
>
> I hope you can still take these for the coming merge window, unless
> new problems come up.
> drivers/platform/x86/wmi.c
g messages in this case, and in particular only
about 3 bytes (btw, if needed it might be easily expanded for up to 64
bytes or even with run-time adjusted length).
> but I don't have a particularly strong opinion
> either way. Applied.
Thanks.
--
Andy Shevchenko
Intel Finland Oy
__
rite the format
> string to accept only one argument - the buffer - with "%3ph"
> specifier.
>
+Cc maintainers
> Signed-off-by: Dmitry Rozhkov
> Suggested-by: Andy Shevchenko
> ---
> drivers/gpu/drm/radeon/radeon_dp_mst.c | 4 ++--
> 1 file changed, 2 insertions(+),
as a timer interrupt.
> */
> static void tpd_led_update(struct work_struct *work)
> - {
> +{
> struct eeepc_laptop *eeepc;
>
> eeepc = container_of(work, struct eeepc_laptop, tpd_led_work);
> diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-
; AMD_141b_MMIO_HIGH_MMIOBASE_MASK) |
> ^~
>arch/x86/pci/fixup.c:687:21: warning: right shift count >= width of type
> [-Wshift-count-overflow]
> res->end + 1) >> 40) << AMD_141b_MMIO_HIGH_MMI
On Fri, Jun 9, 2017 at 11:59 AM, Christian König
wrote:
> From: Christian König
>
> This way we can savely call it on SI as well.
s/savely/safely
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/am
t the doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
Comment why it's used here.
--
With Best Regards,
Andy Shevchenko
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
ree(res);
> + return;
> + }
> +
> + base = ((res->start >> 8) & 0xff00) | 0x3;
> + limit = ((res->end + 1) >> 8) & 0xff00;
> + high = ((res->start >> 40) &
turn -ENOTSUPP;
> +
> + if (!(sizes & (1 << size)))
BIT(size) ?
> + return -EINVAL;
> +
and
old = pci_rbar_get_current_size(dev, resno);
here
> + if (old < 0)
> + return old;
> +error_resize:
> + pci_rbar_set_size(dev, resno, old);
> + res->end = res->start + (1ULL << (old + 20)) - 1;
BIT_ULL(old + 20) ?
--
With Best Regards,
Andy Shevchenko
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
se ack patch [5/5] of this series, barring any objections.
>
> I'll move the apple-gmux patch to the end of the series, so merging that
> one can be postponed until Darren and Andy find the time to look at it.
Yeah, please resend. It's probably buried in the pile of deleted
llX\n",
> (uint64_t)adev->doorbell.base);
> DRM_INFO("doorbell mmio size: %u\n", (unsigned)adev->doorbell.size);
It seems I sent patch to remove those at all, but if you wish to leave
them, please convert to %pap and remove explicit casting.
-
f resizing was successful, false otherwise.
> + */
> +bool pci_rbar_set_size(struct pci_dev *pdev, int bar, int size)
I would return int and error code. It would be better in the future
and seems in alignment with above.
> +{
> + int pos, nbars;
> + u32 ctrl;
> + in
he doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
No way to recover?!
> +}
> +
--
With Best Regards,
Andy Shevchenko
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
53 matches
Mail list logo
