Re: [PATCH 12/18] arch/parisc: Implement fb_is_primary_device() under arch/parisc
Am Mittwoch, 5. April 2023, 17:05:48 CEST schrieb Thomas Zimmermann: > Move PARISC's implementation of fb_is_primary_device() into the > architecture directory. This the place of the declaration and > where other architectures implement this function. No functional > changes. > diff --git a/arch/parisc/video/fbdev.c b/arch/parisc/video/fbdev.c > new file mode 100644 > index ..4a0ae08fc75b > --- /dev/null > +++ b/arch/parisc/video/fbdev.c > @@ -0,0 +1,27 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (C) 2000 Philipp Rumpf > + * Copyright (C) 2001-2020 Helge Deller > + * Copyright (C) 2001-2002 Thomas Bogendoerfer > + */ > + > +#include > + > +#include > + > +#include > + > +int fb_is_primary_device(struct fb_info *info) > +{ Looking at this makes me wonder why the argument to all of these functions isn't const? Not your fault, but could be a candidate for patch #19? Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 00/18] arch: Consolidate
Am Mittwoch, 5. April 2023, 17:05:36 CEST schrieb Thomas Zimmermann: > Various architectures provide with helpers for fbdev ^ *lol* Eike signature.asc Description: This is a digitally signed message part.
Re: [PATCH v4 4/6] treewide: use get_random_u32() when possible
> diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c > index 7c37e09c92da..18c4f0e3e906 100644 > --- a/arch/parisc/kernel/process.c > +++ b/arch/parisc/kernel/process.c > @@ -288,7 +288,7 @@ __get_wchan(struct task_struct *p) > > static inline unsigned long brk_rnd(void) > { > - return (get_random_int() & BRK_RND_MASK) << PAGE_SHIFT; > + return (get_random_u32() & BRK_RND_MASK) << PAGE_SHIFT; > } Can't this be prandom_u32_max(BRK_RND_MASK + 1) << PAGE_SHIFT ? More similar code with other masks follows below. > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c index 329ff75b80b9..7bd1861ddbdf > 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -137,12 +137,12 @@ static u64 random_offset(u64 start, u64 end, u64 len, > u64 align) range = round_down(end - len, align) - round_up(start, align); > if (range) { > if (sizeof(unsigned long) == sizeof(u64)) { > - addr = get_random_long(); > + addr = get_random_u64(); > } else { > - addr = get_random_int(); > + addr = get_random_u32(); > if (range > U32_MAX) { > addr <<= 32; > - addr |= get_random_int(); > + addr |= get_random_u32(); > } > } > div64_u64_rem(addr, range, ); How about if (sizeof(unsigned long) == sizeof(u64) || range > U32_MAX) addr = get_random_u64(); else addr = get_random_u32(); > diff --git a/drivers/infiniband/hw/cxgb4/cm.c > b/drivers/infiniband/hw/cxgb4/cm.c index 14392c942f49..499a425a3379 100644 > --- a/drivers/infiniband/hw/cxgb4/cm.c > +++ b/drivers/infiniband/hw/cxgb4/cm.c > @@ -734,7 +734,7 @@ static int send_connect(struct c4iw_ep *ep) > >com.remote_addr; > int ret; > enum chip_type adapter_type = ep->com.dev->rdev.lldi.adapter_type; > - u32 isn = (prandom_u32() & ~7UL) - 1; > + u32 isn = (get_random_u32() & ~7UL) - 1; > struct net_device *netdev; > u64 params; > > @@ -2469,7 +2469,7 @@ static int accept_cr(struct c4iw_ep *ep, struct > sk_buff *skb, } > > if (!is_t4(adapter_type)) { > - u32 isn = (prandom_u32() & ~7UL) - 1; > + u32 isn = (get_random_u32() & ~7UL) - 1; u32 isn = get_random_u32() | 0x7; Same code comes later again. > diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c > index 50bcf745e816..4bdaf4aa7007 100644 > --- a/drivers/mtd/nand/raw/nandsim.c > +++ b/drivers/mtd/nand/raw/nandsim.c > @@ -1402,7 +1402,7 @@ static int ns_do_read_error(struct nandsim *ns, int > num) > > static void ns_do_bit_flips(struct nandsim *ns, int num) > { > - if (bitflips && prandom_u32() < (1 << 22)) { > + if (bitflips && get_random_u32() < (1 << 22)) { Doing "get_random_u16() < (1 << 6)" should have the same probability with only 2 bytes of random, no? > diff --git a/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.c > b/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.c index > ac452a0111a9..b71ce6c5b512 100644 > --- a/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.c > +++ b/drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_cm.c > @@ -1063,7 +1063,7 @@ static void chtls_pass_accept_rpl(struct sk_buff *skb, > opt2 |= WND_SCALE_EN_V(WSCALE_OK(tp)); > rpl5->opt0 = cpu_to_be64(opt0); > rpl5->opt2 = cpu_to_be32(opt2); > - rpl5->iss = cpu_to_be32((prandom_u32() & ~7UL) - 1); > + rpl5->iss = cpu_to_be32((get_random_u32() & ~7UL) - 1); > set_wr_txq(skb, CPL_PRIORITY_SETUP, csk->port_id); > t4_set_arp_err_handler(skb, sk, chtls_accept_rpl_arp_failure); > cxgb4_l2t_send(csk->egress_dev, skb, csk->l2t_entry); > diff --git a/drivers/net/ethernet/rocker/rocker_main.c > b/drivers/net/ethernet/rocker/rocker_main.c index > fc83ec23bd1d..8c3bbafabb07 100644 > --- a/drivers/net/ethernet/rocker/rocker_main.c > +++ b/drivers/net/ethernet/rocker/rocker_main.c > @@ -139,9 +139,9 @@ static int rocker_reg_test(const struct rocker *rocker) > return -EIO; > } > > - rnd = prandom_u32(); > + rnd = get_random_u32(); > rnd <<= 31; > - rnd |= prandom_u32(); > + rnd |= get_random_u32(); > rocker_write64(rocker, TEST_REG64, rnd); > test_reg = rocker_read64(rocker, TEST_REG64); > if (test_reg != rnd * 2) { > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c index > fabfbb0b40b0..374e1cc07a63 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c > @@ -177,7 +177,7 @@ static int
Re: [PATCH] agp: parisc-agp: fix section mismatch warning
Am Samstag, 27. November 2021, 05:57:57 CET schrieb Randy Dunlap: > Fix section mismatch warning in parisc-agp: Too late ;) https://lore.kernel.org/linux-parisc/20211126154754.263487-1-del...@gmx.de/ signature.asc Description: This is a digitally signed message part.
Re: [PATCH] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()
Markus Elfring wrote: > From: Markus Elfring> Date: Fri, 24 Nov 2017 22:22:06 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/video/fbdev/stifb.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c > index 6ded5c198998..fe217a2f7d21 100644 > --- a/drivers/video/fbdev/stifb.c > +++ b/drivers/video/fbdev/stifb.c > @@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct > *sti, int bpp_pref) int bpp, xres, yres; > > fb = kzalloc(sizeof(*fb), GFP_ATOMIC); > - if (!fb) { > - printk(KERN_ERR "stifb: Could not allocate stifb structure\n"); > + if (!fb) > return -ENODEV; > - } > > info = >info; This should be -ENOMEM. Eike signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM: clean up and document parsing of video= parameter
[PATCH] DRM: clean up and document parsing of video= parameter
The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer --- Documentation/fb/modedb.txt | 21 +- drivers/gpu/drm/drm_modes.c | 87 +- 2 files changed, 78 insertions(+), 30 deletions(-) diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt index ec4dee7..16aa084 100644 --- a/Documentation/fb/modedb.txt +++ b/Documentation/fb/modedb.txt @@ -20,7 +20,7 @@ in a video= option, fbmem considers that to be a global video mode option. Valid mode specifiers (mode_option argument): -x[M][R][-][@][i][m] +x[M][R][-][@][i][m][eDd] [-][@] with , , and decimal numbers and a string. @@ -36,6 +36,21 @@ pixels and 1.8% of yres). Sample usage: 1024x768M at 60m - CVT timing with margins +DRM drivers also add options to enable or disable outputs: + +'e' will force the display to be enabled, i.e. it will override the detection +if a display is connected. 'D' will force the display to be enabled and use +digital output. This is useful for outputs that have both analog and digital +signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd' +is specified the output is disabled. + +You can additionally specify which output the options matches to. +To force the VGA output to be enabled and drive a specific mode say: +video=VGA-1:1280x1024 at 60me + +Specifying the option multiple times for different ports is possible, e.g.: +video=LVDS-1:d video=HDMI-1:D + * oOo * oOo * oOo * oOo * oOo * oOo * oOo * What is the VESA(TM) Coordinated Video Timings (CVT)? @@ -132,5 +147,5 @@ There may be more modes. tridentfb - Trident (Cyber)blade chipset frame buffer vt8623fb - VIA 8623 frame buffer -BTW, only a few drivers use this at the moment. Others are to follow -(feel free to send patches). +BTW, only a few fb drivers use this at the moment. Others are to follow +(feel free to send patches). The DRM drivers also support this. diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index c2d32f2..ad74fb4 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -994,9 +994,10 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, { const char *name; unsigned int namelen; - int res_specified = 0, bpp_specified = 0, refresh_specified = 0; + bool res_specified = false, bpp_specified = false, refresh_specified = false; unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0; - int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0; + bool yres_specified = false, cvt = false, rb = false; + bool interlace = false, margins = false, was_digit = false; int i; enum drm_connector_force force = DRM_FORCE_UNSPECIFIED; @@ -1015,54 +1016,65 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, for (i = namelen-1; i >= 0; i--) { switch (name[i]) { case '@': - namelen = i; if (!refresh_specified && !bpp_specified && - !yres_specified) { + !yres_specified && !cvt && !rb && was_digit) { refresh = simple_strtol([i+1], NULL, 10); - refresh_specified = 1; - if (cvt || rb) - cvt = 0; + refresh_specified = true; + was_digit = false; } els
[PATCH] DRM: clean up and document parsing of video= parameter
From a8163a0acef17c66521de37464732a2a4f9e50ca Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer eike-ker...@sf-tec.de Date: Wed, 15 Jun 2011 11:27:02 +0200 Subject: [PATCH] DRM: clean up and document parsing of video= parameter The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer eike-ker...@sf-tec.de --- Documentation/fb/modedb.txt | 21 +- drivers/gpu/drm/drm_modes.c | 87 +- 2 files changed, 78 insertions(+), 30 deletions(-) diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt index ec4dee7..16aa084 100644 --- a/Documentation/fb/modedb.txt +++ b/Documentation/fb/modedb.txt @@ -20,7 +20,7 @@ in a video= option, fbmem considers that to be a global video mode option. Valid mode specifiers (mode_option argument): -xresxyres[M][R][-bpp][@refresh][i][m] +xresxyres[M][R][-bpp][@refresh][i][m][eDd] name[-bpp][@refresh] with xres, yres, bpp and refresh decimal numbers and name a string. @@ -36,6 +36,21 @@ pixels and 1.8% of yres). Sample usage: 1024x768M@60m - CVT timing with margins +DRM drivers also add options to enable or disable outputs: + +'e' will force the display to be enabled, i.e. it will override the detection +if a display is connected. 'D' will force the display to be enabled and use +digital output. This is useful for outputs that have both analog and digital +signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd' +is specified the output is disabled. + +You can additionally specify which output the options matches to. +To force the VGA output to be enabled and drive a specific mode say: +video=VGA-1:1280x1024@60me + +Specifying the option multiple times for different ports is possible, e.g.: +video=LVDS-1:d video=HDMI-1:D + * oOo * oOo * oOo * oOo * oOo * oOo * oOo * What is the VESA(TM) Coordinated Video Timings (CVT)? @@ -132,5 +147,5 @@ There may be more modes. tridentfb - Trident (Cyber)blade chipset frame buffer vt8623fb - VIA 8623 frame buffer -BTW, only a few drivers use this at the moment. Others are to follow -(feel free to send patches). +BTW, only a few fb drivers use this at the moment. Others are to follow +(feel free to send patches). The DRM drivers also support this. diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index c2d32f2..ad74fb4 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -994,9 +994,10 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, { const char *name; unsigned int namelen; - int res_specified = 0, bpp_specified = 0, refresh_specified = 0; + bool res_specified = false, bpp_specified = false, refresh_specified = false; unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0; - int yres_specified = 0, cvt = 0, rb = 0, interlace = 0, margins = 0; + bool yres_specified = false, cvt = false, rb = false; + bool interlace = false, margins = false, was_digit = false; int i; enum drm_connector_force force = DRM_FORCE_UNSPECIFIED; @@ -1015,54 +1016,65 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, for (i = namelen-1; i = 0; i--) { switch (name[i]) { case '@': - namelen = i; if (!refresh_specified !bpp_specified - !yres_specified) { + !yres_specified !cvt !rb was_digit) { refresh = simple_strtol(name[i+1], NULL, 10