On Fri, 2023-03-03 at 15:35 -0500, Harry Wentland wrote:
> Actually I was wrong. Too many similar-looking snippets in this
> function made me look at the wrong thing. This change is fine and
> Reviewed-by: Harry Wentland
On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
> The if / else block code has same effect irrespective of the logical
> evaluation. Hence, simply the implementation by removing the unnecessary
> conditional evaluation. While at it, also fix the long line checkpatch
> complaint. Issue ide
On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote:
> a multi-line indent gets curly braces for readability even though
> it's not required by C. And then both sides would get curly braces.
That's more your personal preference than a coding style guideline.
On Wed, 2022-01-19 at 16:00 -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 Sakari strongly follows the 80 rule, which means...
>
> Checkpatch says "
On Sun, 2021-11-14 at 23:14 -0800, Bernard Zhao wrote:
> This change is to remove useless break after return.
[]
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
[]
> @@ -2092,22 +2092,18 @@ static int dce_v8_0_pick_dig_encoder(struct
> drm_encoder *e
On Wed, 2021-09-29 at 19:44 -0600, Jim Cromie wrote:
> There are blocks of DRM_DEBUG calls, consolidate their args into
> single calls. With dynamic-debug in use, each callsite consumes 56
> bytes of callsite data, and this patch removes about 65 calls, so
> it saves ~3.5kb.
>
> no functional cha
t;
> url:
> https://github.com/0day-ci/linux/commits/Joe-Perches/drm-amd-display-Simplify-hdcp-validate_bksv/20210712-034708
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
> config: i386-randconfig-a003-20210712 (attached as .config)
> compiler
On Sun, 2021-07-11 at 19:24 +0200, Len Baker wrote:
> The branches of the "if" statement are the same. So remove the
> unnecessary if and goto statements.
>
> Addresses-Coverity-ID: 1456916 ("Identical code for different branches")
> Fixes: 4c283fdac08ab ("drm/amd/display: Add HDCP module")
> Sign
ksv buffer instead of a loop.
This also avoid a possible unaligned access of the temporary bksv.
Signed-off-by: Joe Perches
---
It seems quite odd 20 bits set is a magic number here.
Should it be a specific be/le value instead?
drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execut
On Sat, 2021-06-12 at 08:42 -0700, Joe Perches wrote:
> The __assign_str macro has an unusual ending semicolon but the vast
> majority of uses of the macro already have semicolon termination.
ping?
___
amd-gfx mailing list
a
4916bb420e6c9842a.ca...@perches.com/
Signed-off-by: Joe Perches
---
V2: Remove semicolon addition to #define VIF_ASSIGN as every use of
this macro already has a semicolon termination.
Compiled x84-64 allyesconfig
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 14
drivers/gpu/d
4916bb420e6c9842a.ca...@perches.com/
Signed-off-by: Joe Perches
---
Resending without all the direct cc's, only the mailing lists as
it seems not to have gone through via vger.
Compiled x84-64 allyesconfig
On Fri, 2021-06-04 at 12:21 -0400, Steven Rostedt wrote:
> I have no problem taking a clean u
4916bb420e6c9842a.ca...@perches.com/
Signed-off-by: Joe Perches
---
Compiled x84-64 allyesconfig
On Fri, 2021-06-04 at 12:21 -0400, Steven Rostedt wrote:
> I have no problem taking a clean up patch that adds semicolons to all
> use cases of "__assign_str()" and ever remove the one from
/n should be \n
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff
On Tue, 2021-03-23 at 14:04 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc warns about an sprintf() that uses the same buffer as source
> and destination, which is undefined behavior in C99:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c: In function
> 'amdgpu_securedisplay_de
On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.
Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewe
On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
https://www.wired.com/story/o
On Sat, 2020-11-21 at 09:18 -0800, James Bottomley wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> > A difficult part of automating commits is composing the subsystem
> > preamble in the commit log. For the ongoing effort of a fixer
> > producing one or two fixes a release the
On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> A difficult part of automating commits is composing the subsystem
> preamble in the commit log. For the ongoing effort of a fixer producing
> one or two fixes a release the use of 'treewide:' does not seem appropriate.
>
> It would be be
On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote:
> We can enforce sysfs_emit going forwards
> using tools like checkpatch
It's not really possible for checkpatch to find or warn about
sysfs uses of sprintf. checkpatch is really just a trivial
line-by-line parser and it has no concept of c
On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.
There were quite literally dozens of logical defects found
by the fallthrough additions. Very few were logging only.
_
On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error
On Mon, 2020-11-23 at 09:33 +1100, Finn Thain wrote:
> On Sun, 22 Nov 2020, Joe Perches wrote:
> > But provably correct conversions IMO _should_ be done and IMO churn
> > considerations should generally have less importance.
[]
> Moreover, the patch review workload for skill
On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote:
> On 11/21/20 9:10 AM, Joe Perches wrote:
> > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> > > A difficult part of automating commits is composing the subsystem
> > > preamble in the commit log. For th
On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto
On Fri, 2020-11-13 at 13:48 +, Lee Jones wrote:
> This patch fixes nearly 400 warnings!
>
> These structures are too widely used in too many varying
> configurations to be split-up into different headers or moved into
> source files.
>
> Instead, we'll mark them as __maybe_unused which tells
On Tue, 2020-10-27 at 09:42 -0700, t...@redhat.com wrote:
> This rfc will describe
> An upcoming treewide cleanup.
> How clang tooling was used to programatically do the clean up.
> Solicit opinions on how to generally use clang tooling.
>
> The clang warning -Wextra-semi-stmt produces about 10k w
On Fri, 2020-10-30 at 09:03 +0100, Greg KH wrote:
> On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote:
> > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
> > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with de
On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if
On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early a
On Sat, 2020-10-17 at 20:21 +0200, Julia Lawall wrote:
> On Sat, 17 Oct 2020, Joe Perches wrote:
> > On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> &g
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > clang has a number of useful, new warnings see
> > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F9
On Mon, 2020-10-05 at 21:50 -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> arch/arc/ implements BUG_ON() with BUG(). ARC has its own BUG()
> function and that function uses pr_warn() as part of its implementation.
>
> Several (8) files in amd/powerplay/ #undef various pr_xyz() functions so
On Wed, 2020-08-05 at 17:27 -0400, Alex Deucher wrote:
> On Wed, Aug 5, 2020 at 4:53 PM Joe Perches wrote:
> > On Wed, 2020-08-05 at 16:01 -0400, Alex Deucher wrote:
> > > On Wed, Aug 5, 2020 at 7:35 AM Colin King
> > > wrote:
> > > > From: Colin Ian Kin
On Wed, 2020-08-05 at 16:01 -0400, Alex Deucher wrote:
> On Wed, Aug 5, 2020 at 7:35 AM Colin King wrote:
> > From: Colin Ian King
> >
> > There is a spelling mistake in a DRM_ERROR message. Fix it.
> >
> > Signed-off-by: Colin Ian King
>
> This is already fixed.
This fix is not in today's -
On Mon, 2020-06-08 at 20:49 +0300, Dan Carpenter wrote:
> On Mon, Jun 08, 2020 at 10:16:27AM -0700, Joe Perches wrote:
> > On Mon, 2020-06-08 at 17:16 +0300, Dan Carpenter wrote:
> > > These lines are a part of the if statement and they are supposed to
> > &g
On Mon, 2020-06-08 at 17:16 +0300, Dan Carpenter wrote:
> These lines are a part of the if statement and they are supposed to
> be indented one more tab.
>
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 d
On Thu, 2020-05-07 at 08:42 +0200, Christian König wrote:
> Am 06.05.20 um 21:01 schrieb Joe Perches:
[]
> > And trivia:
> >
> > The !! uses with bool seem unnecessary and it's probably better
> > to make amdgpu_ras_is_feature_enabled to return bool.
[]
> > d
On Tue, 2020-05-05 at 16:01 +0200, Arnd Bergmann wrote:
> After the structure was padded to 1024 bytes, it is no longer
> suitable for being a local variable, as the function surpasses
> the warning limit for 32-bit architectures:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:587:5: error: stack fra
On Sun, 2020-04-26 at 15:18 +0200, Christian König wrote:
> Am 26.04.20 um 15:12 schrieb Bernard Zhao:
> > Maybe no need to check ws before kmalloc, kmalloc will check
> > itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
> > return
> >
> > Signed-off-by: Bernard Zhao
>
> Reviewed-by:
btw: the debugging macros in atom.c are not good.
It could be something like the below as the output logging is
at best poorly formatted due to the many individual printks
without KERN_ that are emitted on separate lines.
#define ATOM_DEBUG
should probably be commented out.
The debugging macro
On Mon, 2020-04-27 at 14:37 +0800, Jason Yan wrote:
> The '==' expression itself is bool, no need to convert it to bool again.
trivia:
These descriptions are not quite correct.
The operators return an int, either 0 or 1.
-
6.5.8 Relational operators
6 Each of the operators < (le
On Wed, 2020-04-08 at 09:37 -0400, Aurabindo Pillai wrote:
> amdgpu uses lots of pr_* calls for printing error messages.
> With this prefix, errors shall be more obvious to the end
> use regarding its origin, and may help debugging.
>
> Prefix format:
>
> [xxx.x] amdgpu: ...
[]
> diff --git a
On Tue, 2020-03-17 at 17:25 -0700, Nathan Chancellor wrote:
> clang warns:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:6: warning: variable 'shadow'
> is used uninitialized whenever 'if' condition is
> false [-Wsometimes-uninitialized]
> if (offset == grbm_cntl || offset == grbm_idx)
>
On Wed, 2020-03-11 at 17:50 -0400, Felix Kuehling wrote:
> On 2020-03-11 12:51 a.m., Joe Perches wrote:
> > Convert the various uses of fallthrough comments to fallthrough;
> >
> > Done via script
> > Link:
> > https://lore.kernel.org/lkml/b56602fcf79f849e73
Convert the various uses of fallthrough comments to fallthrough;
Done via script
Link:
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 4 ++--
drivers/gpu/drm/amd
Convert the various uses of fallthrough comments to fallthrough;
Done via script
Link:
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 2 +-
1 file changed, 1
Convert the various uses of fallthrough comments to fallthrough;
Done via script
Link:
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 +++---
1 file changed, 3
ex --quiet HEAD --`;
next if (!$?);
# Commit the changes
my $fh;
open($fh, "+>", "cvt_fallthrough.commit_msg") or die "$0: can't create
temporary file: $!\n";
print $fh <https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git@perche
On Sun, 2020-02-02 at 00:11 +0100, Julian Sax wrote:
> During normal usage, especially if jobs are started and stopped in rapid
> succession, the kernel log is filled with messages like this:
>
> [38732.522910] Restoring PASID 0x8003 queues
> [38732.666767] Evicting PASID 0x8003 queues
> [38732.71
On Wed, 2019-11-13 at 20:44 +0800, yu kuai wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c: In function
> ‘gfx_v6_0_constants_init’:
> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:1579:6: warning: variable
> ‘mc_shared_chmap’ set but not used [-Wunused-bu
On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
> Fix a build warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
> warning: 'static' is not at beginning of declaration
> [-Wold-style-declaration]
[]
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/
On Tue, 2019-10-08 at 13:56 +, Harry Wentland wrote:
[]
> > diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> > b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> []
> > @@ -2745,7 +2745,7 @@ static enum bp_result bios_get_board_layout_info(
> > struct bios_parser *bp;
>
On Wed, 2019-09-04 at 08:08 -0400, Sasha Levin wrote:
> it's better to get
> it right rather than to be done quickly :)
That also applies to the initial selection of
patches for the stable trees.
On Thu, 2019-08-01 at 15:02 -0400, Alex Deucher wrote:
> Applied. thanks!
>
> Alex
>
> On Thu, Aug 1, 2019 at 4:39 AM Colin King wrote:
> > From: Colin Ian King
> >
> > There are a few spelling mistakes "unknow" -> "unknown" and
> > "enabeld" -> "enabled". Fix these.
[]
> > diff --git a/drive
On Mon, 2019-06-24 at 11:41 +0800, maowenan wrote:
>
> On 2019/6/23 2:13, Joe Perches wrote:
> > On Sat, 2019-06-22 at 21:05 +0800, Mao Wenan wrote:
> > > There is one warning:
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c: In function ‘amdgpu_pmu_init’:
&g
On Sat, 2019-06-22 at 21:05 +0800, Mao Wenan wrote:
> There is one warning:
> drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c: In function ‘amdgpu_pmu_init’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:249:6: warning: variable ‘ret’ set
> but not used [-Wunused-but-set-variable]
> int ret = 0;
[]
> v1->v
On Thu, 2019-03-21 at 22:10 -0500, Gustavo A. R. Silva wrote:
> Hi Harry,
>
> I noticed this patch is already in mainline, but the stable tag
> was removed. What is the reason for that if this bug is present
> in stable?
It's not a bug, it's just a style issue and
the && use in some compilers it
On Mon, 2018-10-22 at 22:53 +0530, Arun KS wrote:
> Remove managed_page_count_lock spinlock and instead use atomic
> variables.
Perhaps better to define and use macros for the accesses
instead of specific uses of atomic_long_
Something like:
#define totalram_pages()(unsigned
long)atomic
On Fri, 2018-05-25 at 09:41 +0300, Jani Nikula wrote:
> On Thu, 24 May 2018, Joe Perches wrote:
> > There is currently a mixture of octal and symbolic permissions uses
> > in files in drivers/gpu/drm and one file in drivers/gpu.
> >
> > There are ~270 existing
to open parenthesis
o drivers/gpu/drm/msm/adreno/a5xx_debugfs.c has a world-writeable
debug permission for "reset" - perhaps that should be modified
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
Some functions definitions have either the initial open brace and/or
the closing brace outside of column 1.
Move those braces to column 1.
This allows various function analyzers like gnu complexity to work
properly for these modified functions.
Signed-off-by: Joe Perches
Acked-by: Andy
On Wed, 2018-03-21 at 18:26 +, Colin King wrote:
> From: Colin Ian King
>
> The for-loops process data in the mclk_table but use slck_table.count
> as the loop index limit. I believe these are cut-n-paste errors from
> the previous almost identical loops as indicated by static analysis.
> Fi
On Tue, 2018-02-20 at 17:19 +1100, Michael Ellerman wrote:
> Daniel Vetter writes:
> > On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
> > > Le 17/02/2018 à 22:19, Pavel Machek a écrit :
> > > >
> > > > Fix double ;;'s in code.
> > > >
> > > > Signed-off-by: Pavel Machek
> > >
line from xfs_agf_verify
Signed-off-by: Joe Perches
---
git diff -w shows no difference other than the above 'Miscellanea'
(this is against -next, but it applies against Linus' tree
with a couple offsets)
arch/x86/include/asm/atomic64_32.h | 2 +
On Thu, 2017-11-16 at 12:11 -0500, Mimi Zohar wrote:
> On Thu, 2017-11-16 at 07:27 -0800, Joe Perches wrote:
> > Avoid using line continations in formats as that causes unexpected
> > output.
>
> Is having lines greater than 80 characters the preferred method?
yes.
&g
On Thu, 2017-11-16 at 10:38 -0500, Harry Wentland wrote:
> On 2017-11-16 10:27 AM, Joe Perches wrote:
> > Line continuations with excess spacing causes unexpected output.
[]
> > @@ -872,9 +870,8 @@ static bool perform_clock_recovery_sequence(
> > if (retry_count >= LI
Line continuations with excess spacing causes unexpected output.
Miscellanea:
o Added missing '\n' to a few of the coalesced pr_ formats
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 11 -
.../amd/powerplay/hwmgr/process_pptables_v1_0
Avoid using line continations in formats as that causes unexpected
output.
Joe Perches (4):
rk3399_dmc: Fix line continuation format
drm: amd: Fix line continuation formats
[media] dibx000_common: Fix line continuation format
ima: Fix line continuation format
drivers/devfreq
Use a more common logging style.
Miscellanea:
o Coalesce formats and realign arguments
o Neaten a few macros now using pr_
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-
drivers/gpu/drm/amd
Broken up for Daniel Vetter
Joe Perches (3):
gpu: drm: amd/radeon: Convert printk(KERN_ to pr_
gpu: drm: core: Convert printk(KERN_ to pr_
gpu: drm: drivers: Convert printk(KERN_ to pr_
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
Use a more common logging style.
Miscellanea:
o Coalesce formats and realign arguments
o Neaten a few macros now using pr_
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-
drivers/gpu/drm/amd
Joe Perches (2):
drm: Use pr_cont where appropriate
gpu: drm: Convert printk(KERN_ to pr_
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +-
drivers/gpu/drm/amd
se a temporary const char * instead of multiple printks
o Remove trailing space from logging by using a leading space instead
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 70
drivers/gpu/drm/radeon/r600_dpm.c | 71
On Thu, 2017-02-23 at 17:41 +, Emil Velikov wrote:
> On 23 February 2017 at 17:18, Joe Perches wrote:
> > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> > > On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches wrote:
> > > > There are ~4300 uses of pr_w
On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches wrote:
> > There are ~4300 uses of pr_warn and ~250 uses of the older
> > pr_warning in the kernel source tree.
> >
> > Make the use of pr_warn consistent across all
To enable eventual removal of pr_warning
This makes pr_warn use consistent for drivers/gpu
Prior to this patch, there were 15 uses of pr_warning and
20 uses of pr_warn in drivers/gpu
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
drivers/gpu/drm
with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
Miscellanea:
o Coalesce formats and realign arguments
Some files not compiled - no cross-compilers
Joe Perches (35):
alpha: Convert remaining uses of pr_warning to pr_warn
ARM: ep93xx: Convert remaining uses of pr_warning
On Fri, 2016-08-05 at 20:30 -0400, Lyude wrote:
> There's a couple of places where this would be useful for drivers (such
> as reporting DP aux transaction timeouts).
Maybe a single static _rs or one for each type would
be better than an individual _rs per callsite.
__
79 matches
Mail list logo
