[PATCH] vgacon: unconfuse vc_origin when using soft scrollback
When CONFIG_VGACON_SOFT_SCROLLBACK is selected, the VGA display memory
index and vc_visible_origin don't change when scrollback is activated.
The actual screen content is saved away and the scrollbackdata is copied
over it. However the vt code, and /dev/vcs devices in particular, still
expect vc_origin to always point at the actual screen content not the
displayed scrollback content.
So adjust vc_origin to point at the saved screen content when scrollback
is active and set it back to vc_visible_origin when restoring the screen.
This fixes /dev/vcsa that return scrollback content when they
shouldn't (onli /dev/vcsa without a number should), and also fixes
/dev/vcsu that should return scrollback content when scrollback is
active but currently doesn't.
An unnecessary call to vga_set_mem_top() is also removed.
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org # v4.19+
---
I tagged it for stable starting with v4.19 as this is the kernel that
introduced /dev/vcsu* which is directly affected. Users of earlier kernels
most likely won't care.
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 09731b2f68..c6b3bdbbdb 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -271,6 +271,7 @@ static void vgacon_scrollback_update(struct vc_data *c, int
t, int count)
static void vgacon_restore_screen(struct vc_data *c)
{
+ c->vc_origin = c->vc_visible_origin;
vgacon_scrollback_cur->save = 0;
if (!vga_is_gfx && !vgacon_scrollback_cur->restore) {
@@ -287,8 +288,7 @@ static void vgacon_scrolldelta(struct vc_data *c, int lines)
int start, end, count, soff;
if (!lines) {
- c->vc_visible_origin = c->vc_origin;
- vga_set_mem_top(c);
+ vgacon_restore_screen(c);
return;
}
@@ -298,6 +298,7 @@ static void vgacon_scrolldelta(struct vc_data *c, int lines)
if (!vgacon_scrollback_cur->save) {
vgacon_cursor(c, CM_ERASE);
vgacon_save_screen(c);
+ c->vc_origin = (unsigned long)c->vc_screenbuf;
vgacon_scrollback_cur->save = 1;
}
@@ -335,7 +336,7 @@ static void vgacon_scrolldelta(struct vc_data *c, int lines)
int copysize;
int diff = c->vc_rows - count;
- void *d = (void *) c->vc_origin;
+ void *d = (void *) c->vc_visible_origin;
void *s = (void *) c->vc_screenbuf;
count *= c->vc_size_row;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, 9 Oct 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Acked-by: Nicolas Pitre
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
> put_page(page);
> } else
> memset(data, 0, PAGE_SIZE);
> @@ -826,7 +826,7 @@ static int cramfs_readpage(struct file *file, struct page
> *page)
>
> maxblock = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> bytes_filled = 0;
> - pgdata = kmap(page);
> + pgdata = kmap_thread(page);
>
> if (page->index < maxblock) {
> struct super_block *sb = inode->i_sb;
> @@ -914,13 +914,13 @@ static int cramfs_readpage(struct file *file, struct
> page *page)
>
> memset(pgdata + bytes_filled, 0, PAGE_SIZE - bytes_filled);
> flush_dcache_page(page);
> - kunmap(page);
> + kunmap_thread(page);
> SetPageUptodate(page);
> unlock_page(page);
> return 0;
>
> err:
> - kunmap(page);
> + kunmap_thread(page);
> ClearPageUptodate(page);
> SetPageError(page);
> unlock_page(page);
> --
> 2.28.0.rc0.12.gb6a658bd00c9
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Wed, 8 Apr 2020, Arnd Bergmann wrote: > Hi everyone, > > I've just restarted doing randconfig builds on top of mainline Linux and > found a couple of regressions with missing dependency from the recent > change in the "imply" keyword in Kconfig, presumably these two patches: > > 3a9dd3ecb207 kconfig: make 'imply' obey the direct dependency > def2fbffe62c kconfig: allow symbols implied by y to become m > > I have created workarounds for the Kconfig files, which now stop using > imply and do something else in each case. I don't know whether there was > a bug in the kconfig changes that has led to allowing configurations that > were not meant to be legal even with the new semantics, or if the Kconfig > files have simply become incorrect now and the tool works as expected. In most cases it is the code that has to be fixed. It typically does: if (IS_ENABLED(CONFIG_FOO)) foo_init(); Where it should rather do: if (IS_REACHABLE(CONFIG_FOO)) foo_init(); A couple of such patches have been produced and queued in their respective trees already. Nicolas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Wed, 8 Apr 2020, Arnd Bergmann wrote: > On Wed, Apr 8, 2020 at 10:38 PM Nicolas Pitre wrote: > > On Wed, 8 Apr 2020, Arnd Bergmann wrote: > > > I have created workarounds for the Kconfig files, which now stop using > > > imply and do something else in each case. I don't know whether there was > > > a bug in the kconfig changes that has led to allowing configurations that > > > were not meant to be legal even with the new semantics, or if the Kconfig > > > files have simply become incorrect now and the tool works as expected. > > > > In most cases it is the code that has to be fixed. It typically does: > > > > if (IS_ENABLED(CONFIG_FOO)) > > foo_init(); > > > > Where it should rather do: > > > > if (IS_REACHABLE(CONFIG_FOO)) > > foo_init(); > > > > A couple of such patches have been produced and queued in their > > respective trees already. > > I try to use IS_REACHABLE() only as a last resort, as it tends to > confuse users when a subsystem is built as a module and already > loaded but something relying on that subsystem does not use it. Then this is a usage policy issue, not a code correctness issue. The correctness issue is fixed with IS_REACHABLE(). If you want to enforce a usage policy then this goes in Kconfig. But you still can do both. Nicolas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, 16 Apr 2020, Arnd Bergmann wrote: > On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula > wrote: > > > > On Thu, 16 Apr 2020, Arnd Bergmann wrote: > > > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed > > > wrote: > > >> BTW how about adding a new Kconfig option to hide the details of > > >> ( BAR || !BAR) ? as Jason already explained and suggested, this will > > >> make it easier for the users and developers to understand the actual > > >> meaning behind this tristate weird condition. > > >> > > >> e.g have a new keyword: > > >> reach VXLAN > > >> which will be equivalent to: > > >> depends on VXLAN && !VXLAN > > > > > > I'd love to see that, but I'm not sure what keyword is best. For your > > > suggestion of "reach", that would probably do the job, but I'm not > > > sure if this ends up being more or less confusing than what we have > > > today. > > > > Ah, perfect bikeshedding topic! > > > > Perhaps "uses"? If the dependency is enabled it gets used as a > > dependency. > > That seems to be the best naming suggestion so far What I don't like about "uses" is that it doesn't convey the conditional dependency. It could be mistaken as being synonymous to "select". What about "depends_if" ? The rationale is that this is actually a dependency, but only if the related symbol is set (i.e. not n or empty). > Right. OTOH whoever implements it gets to pick the color of the > bikeshed. ;-) Absolutely. But some brainstorming can't hurt. Nicolas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] ARM: asm/div64.h: adjust to generic codde
[added Mike/linux-clk and David/dri-devel] A patch I produced is now highlighting existing bugs in the drivers listed below. On Tue, 3 Nov 2015, kbuild test robot wrote: > Hi Nicolas, > > [auto build test WARNING on asm-generic/master -- if it's inappropriate base, > please suggest rules for selecting the more suitable base] > > url: > https://github.com/0day-ci/linux/commits/Nicolas-Pitre/div64-h-optimize-do_div-for-power-of-two-constant-divisors/20151103-065348 > config: arm-multi_v7_defconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > All warnings (new ones prefixed by >>): > >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from include/asm-generic/bug.h:13, > from arch/arm/include/asm/bug.h:62, > from include/linux/bug.h:4, > from include/linux/io.h:23, > from include/linux/clk-provider.h:14, > from drivers/clk/imx/clk-pllv1.c:1: >drivers/clk/imx/clk-pllv1.c: In function 'clk_pllv1_recalc_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/imx/clk-pllv1.c:99:2: note: in expansion of macro 'do_div' > do_div(ll, mfd + 1); > ^ Here the problem is in clk-pllv1.c where the ll variable is declared as a long long. It should be an unsigned long long, or better yet an uint64_t or u64. > -- >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from drivers/clk/imx/clk-pllv2.c:1: >drivers/clk/imx/clk-pllv2.c: In function '__clk_pllv2_recalc_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/imx/clk-pllv2.c:103:2: note: in expansion of macro 'do_div' > do_div(temp, mfd + 1); > ^ Same thing: temp is declared as a s64. It should be u64. >drivers/clk/imx/clk-pllv2.c: In function '__clk_pllv2_set_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ >drivers/clk/imx/clk-pllv2.c:145:2: note: in expansion of macro 'do_div' > do_div(temp64, quad_parent_rate / 100); > ^ Ditto here. > -- >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from drivers/clk/tegra/clk-divider.c:17: >drivers/clk/tegra/clk-divider.c: In function 'get_div': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/tegra/clk-divider.c:50:2: note: in expansion of macro 'do_div' > do_div(divider_ux1, rate); > ^ Ditto here. > -- >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from drivers/clk/ti/clkt_dpll.c:17: >drivers/clk/ti/clkt_dpll.c: In function 'omap2_get_dpll_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/ti/clkt_dpll.c:266:2: note: in expansion of macro 'do_div' > do_div(dpll_clk, dpll_div + 1); > ^ Ditto here. > -- >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from include/linux/clk.h:16, > from drivers/clk/ti/fapll.c:12: >drivers/clk/ti/fapll.c: In function 'ti_fapll_recalc_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/ti/fapll.c:182:3: note: in expansion of mac
[PATCH] nouveau/nvkm/subdev/clk/gk20a.c: fix wrong do_div() usage
do_div() must only be used with a u64 dividend. Signed-off-by: Nicolas Pitre diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c index 254094ab7f..5da2aa8cc3 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c @@ -141,9 +141,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk *clk) rate = clk->parent_rate * clk->n; divider = clk->m * pl_to_div[clk->pl]; - do_div(rate, divider); - return rate / 2; + return rate / divider / 2; } static int
[PATCH] drm/mgag200/mgag200_mode.c: fix wrong do_div() usage
do_div() is meant to be used with an unsigned dividend.
Signed-off-by: Nicolas Pitre
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index c99d3fe128..1d4c480f5c 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1564,7 +1564,7 @@ static uint32_t mga_vga_calculate_mode_bandwidth(struct
drm_display_mode *mode,
int bits_per_pixel)
{
uint32_t total_area, divisor;
- int64_t active_area, pixels_per_second, bandwidth;
+ uint64_t active_area, pixels_per_second, bandwidth;
uint64_t bytes_per_pixel = (bits_per_pixel + 7) / 8;
divisor = 1024;
[PATCH] nouveau/nvkm/subdev/clk/gk20a.c: fix wrong do_div() usage
On Fri, 4 Dec 2015, Thierry Reding wrote:
> On Tue, Nov 03, 2015 at 05:01:46PM -0500, Nicolas Pitre wrote:
> > do_div() must only be used with a u64 dividend.
> >
> > Signed-off-by: Nicolas Pitre
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> > index 254094ab7f..5da2aa8cc3 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> > @@ -141,9 +141,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk *clk)
> >
> > rate = clk->parent_rate * clk->n;
> > divider = clk->m * pl_to_div[clk->pl];
> > - do_div(rate, divider);
> >
> > - return rate / 2;
> > + return rate / divider / 2;
> > }
> >
> > static int
>
> This causes build breakage on 32-bit ARM.
Funny, because the above _fixes_ build warnings on 32-bit ARM for me.
> I'm also confused by the commit message because the code that I'm
> looking at has u64 rate and u32 divider,
If I look at drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
in v4.4-rc3 between line 137 and line 147, I see this:
gk20a_pllg_calc_rate(struct gk20a_clk *clk)
{
u32 rate;
u32 divider;
rate = clk->parent_rate * clk->n;
divider = clk->m * pl_to_div[clk->pl];
do_div(rate, divider);
return rate / 2;
}
So clearly both rate and divider are u32 variables and do_div() should
not be used.
Here's the warning:
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function
'gk20a_pllg_calc_rate':
include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer
types lacks a cast
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:144:2: note: in expansion of
macro 'do_div'
do_div(rate, divider);
^
The corresponding line number in vanilla v4.4-rc3 for
include/asm-generic/div64.h is line 43.
Nicolas
Re: [PATCH] console/dummy: leave .con_font_get set to NULL
On Mon, 15 Jan 2018, Bartlomiej Zolnierkiewicz wrote: > On Friday, January 05, 2018 04:42:58 PM Nicolas Pitre wrote: > > > > When this method is set, the caller expects struct console_font fields > > to be properly initialized when it returns. Leave it unset otherwise > > nonsensical (leaked kernel stack) values are returned to user space. > > > > Signed-off-by: Nicolas Pitre > > Cc: sta...@kernel.org > > Please check your patches with tools/checkpatch.pl script: > > ERROR: The 'stable' address should be 'sta...@vger.kernel.org' > #9: > Cc: sta...@kernel.org Oops. I cut and pasted it it from commit ea0ee33988778fb73e4f4. ;-) Nicolas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] console/dummy: leave .con_font_get set to NULL
When this method is set, the caller expects struct console_font fields
to be properly initialized when it returns. Leave it unset otherwise
nonsensical (leaked kernel stack) values are returned to user space.
Signed-off-by: Nicolas Pitre
Cc: sta...@kernel.org
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 9269d56852..b90ef96e43 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -67,7 +67,6 @@ const struct consw dummy_con = {
.con_switch = DUMMY,
.con_blank = DUMMY,
.con_font_set =DUMMY,
-.con_font_get =DUMMY,
.con_font_default =DUMMY,
.con_font_copy = DUMMY,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ARM: add get_user() support for 8 byte types
On Thu, 15 Nov 2012, Rob Clark wrote:
> From: Rob Clark
>
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).
>
> v1: original
> v2: pass correct size to check_uaccess, and better handling of narrowing
> double word read with __get_user_xb() (Russell King's suggestion)
> v3: explain in comment about why this works for narrowing fetch to 1,
> 2, or 4 byte type on ARM.
>
> Signed-off-by: Rob Clark
Acked-by: Nicolas Pitre
> ---
> arch/arm/include/asm/uaccess.h | 22 +-
> arch/arm/lib/getuser.S | 17 -
> 2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
> index 7e1f760..4cfa793 100644
> --- a/arch/arm/include/asm/uaccess.h
> +++ b/arch/arm/include/asm/uaccess.h
> @@ -100,6 +100,7 @@ static inline void set_fs(mm_segment_t fs)
> extern int __get_user_1(void *);
> extern int __get_user_2(void *);
> extern int __get_user_4(void *);
> +extern int __get_user_8(void *);
>
> #define __GUP_CLOBBER_1 "lr", "cc"
> #ifdef CONFIG_CPU_USE_DOMAINS
> @@ -108,6 +109,7 @@ extern int __get_user_4(void *);
> #define __GUP_CLOBBER_2 "lr", "cc"
> #endif
> #define __GUP_CLOBBER_4 "lr", "cc"
> +#define __GUP_CLOBBER_8 "lr", "cc"
>
> #define __get_user_x(__r2,__p,__e,__l,__s) \
> __asm__ __volatile__ ( \
> @@ -118,11 +120,23 @@ extern int __get_user_4(void *);
> : "0" (__p), "r" (__l) \
> : __GUP_CLOBBER_##__s)
>
> +/*
> + * Narrowing a double-word get into a single 32bit word register, which works
> + * for 1, 2, or 4 byte types on ARM because there are no integer registers
> + * smaller than 32bit
> + */
> +#ifdef BIG_ENDIAN
> +#define __get_user_xb(__r2,__p,__e,__l,__s) \
> + __get_user_x(__r2,(uintptr_t)__p + 4,__e,__l,__s)
> +#else
> +#define __get_user_xb __get_user_x
> +#endif
> +
> #define __get_user_check(x,p)
> \
> ({ \
> unsigned long __limit = current_thread_info()->addr_limit - 1; \
> register const typeof(*(p)) __user *__p asm("r0") = (p);\
> - register unsigned long __r2 asm("r2"); \
> + register typeof(x) __r2 asm("r2"); \
> register unsigned long __l asm("r1") = __limit; \
> register int __e asm("r0"); \
> switch (sizeof(*(__p))) { \
> @@ -135,6 +149,12 @@ extern int __get_user_4(void *);
> case 4: \
> __get_user_x(__r2, __p, __e, __l, 4); \
> break; \
> + case 8: \
> + if (sizeof((x)) < 8)\
> + __get_user_xb(__r2, __p, __e, __l, 4); \
> + else\
> + __get_user_x(__r2, __p, __e, __l, 8); \
> + break; \
> default: __e = __get_user_bad(); break; \
> } \
> x = (typeof(*(p))) __r2;\
> diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
> index 9b06bb4..ed98707 100644
> --- a/arch/arm/lib/getuser.S
> +++ b/arch/arm/lib/getuser.S
> @@ -18,7 +18,7 @@
> * Inputs: r0 contains the address
> * r1 contains the address limit, which must be preserved
> * Outputs: r0 is the error code
> - * r2 contains the zero-extended value
> + * r2, r3 contains the zero-extended value
> * lr corrupted
> *
> * No other registers must be altered. (see
> @@ -66,6 +66,19 @@ ENTRY(__get_user_4)
> mov pc, lr
> ENDPROC(__get_user_4)
>
> +ENTRY(__get_user_8)
> + check_uaccess r0, 8, r1, r2, __get_user_bad
> +#ifdef CONFIG_THUMB2_KERNEL
> +5: TUSER(ldr)r2, [r0]
> +6: TUSER(ldr)r3, [r0, #4
Re: Freescale Linux BSP review
On Wed, 22 Dec 2010, David Rusling wrote: > Now for a bit of a rant. Personally, I have a deep and abiding > respect for open source (for me, it's the key social invention of the > internet age), however I also recognise that it would not exist > without companies using open source as part of their products. Let's > face it, an awful lot of open source engineers are getting their > mortgages paid by companies that make use of open source. I cannot be in full agreement with the above statement. I think the reality is way more nuanced than that. The truth of the matter is that Open Source came into existence without and despite involvement from the corporate world. And the very reason it started to attract interest from the corporate world is because of Open Source's superior quality and performance at a lower cost. Open Source would have existed even without companies using it as you would still have those Open Source activists using it themselves in your product, even without the help of the corporate money. The company involvement in Open Source did indeed accelerate its development by paying many people to work on it full time. But Open Source would still be there and still be in good shape even if corporate involvement didn't happen, just like it was before. And this superior quality and performance characteristics of Open Source are not a coincidence. They are the first motives in a world which is not driven by monetary profits, unlike most if not all the proprietary alternatives. The people leading Open Source are driven by the technical excellence of their work and the recognition they get from their peers. Money is a far secondary motive, and in this age you can choose between different sources of sufficient money not to have to worry about it anymore and compromise too much on your primary motives when you already have a track record in this Open Source world. So to say that the corporate world might need to consider Open Source to be competitive and survive, but the reverse is not true i.e. Open Source doesn't _require_ the corporate world to survive. > No company invests in open source for philanthropic reasons; they > understand that it is necessary for their businesses. The tricky > problem is always in how ethical a company's usage is (and I use the > word 'ethical' deliberately because this is wider than mere legal > words smithing); whenever I give talks on GPL, I emphasise both the > moral as well as the legal duties. In my experience, most companies > struggle to understand open source when they first start to interact > with it. It usually takes some open source zealots within the company > to persuade their management of the right way to behave. The best way > to get companies to change their behaviour is to find them and support > them. Making threatening GPL noises in email does not help them in > any way. Here I'm more in agreement with you. However this is again not the full picture. Ethical or not, the first motive of a company is to make profits. If that was easy to get away with it, all that companies would do is simply to grab this body of source code for themselves and never contribute back. And a sizable number of companies, even some sizable companies, are doing just that. While this isn't going to kill Open Source, this certainly makes it weaker because this is contrary to that very first principle that made Open Source a success in the first place. Companies doing that are after the immediate monetary profit and not the technical excellence and performances. But even when leaving the ethical aspect aside, it is not going to be profitable for companies in the long term to grab Open Source results and move it back to the legacy proprietary model. Doing that will be to their disadvantage when some other companies come along to compete on the market using Open Source to its fullest technical excellence and performance potential. Fortunately, a sizable number of companies, even sizable ones, did understand that already. But... while some companies are struggling to understand how to interact with Open Source, the Open Source world still dash ahead without much concerns for corporate profits. As said above, those strange Open Source animals are motivated by the technical excellence of their work, and they're going to fight on that front against anything that might affect or prevent that goal. This is again why Open Source has always progressed even despite initial attempts to kill it from some corporations. So far, Linux has always been immune to monetary forces, whether those forces were against it or not. So it is fair to say that Open Source survival depends primarily on its technical advantages above anything else. In conclusion: don't get surprised if technically inferior propositions, such as proprietary 3D libraries coupled with kernel-side interfaces, are met with strong
Re: Freescale Linux BSP review
On Wed, 22 Dec 2010, Tom Gall wrote: > The very important part of this whole discussion is getting arm Linux and it's > 3d driver situation so it TOO is the best. > > Right now it's not and pointing to other elements of the system and saying > "it's great" is besides the point. My whole point, if I may resume my conclusion to a few words, is that most Open Source folks don't care if you can't open your code for whatever reasons. That won't encourage them to compromise on their fundamental principle. It's up to those companies to balance the cost of maintaining their ad hoc proprietary stuff themselves vs the cost of opening up their code so it can be merged upstream. > This discussion is good, but for it to have a positive outcome, we need to > turn the direction back to how we get to the end goal > for arm 3D graphics. Absolutely! > It's not probably going to happen at once with one patch that does > what everyone wants. I think it's going to take graduated steps and > some compromises. Yes. However, as I said, those compromises may not come on the technical aspects of the kernel interfaces. Just like it is unlikely for companies to ever compromise on their profits. Any compromise touching any of those fundamental aspects for their respective parties is bound to always fail. In other words, let's save ourselves some energy and give up on the idea that a kernel shim only for a binary only user space library is going to ever be accepted in mainline. This simply will never happen, period. Nicolas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Freescale Linux BSP review
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote: > On 22 December 2010 20:39, Piotr Gluszenia Slawinski > wrote: > >> So to say that the corporate world might need to consider Open Source to > >> be competitive and survive, but the reverse is not true i.e. Open Source > >> doesn't _require_ the corporate world to survive. > > > > i agree with it fully, and to support this claim i want to remind the > > simple rule of capital accumulation. Open Source community > > _already_ accumulated enough _capital_ in form of algorithms, > > implementations, social relations, experience, documentation and > > augmentation with education system . > > I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually > thrive and make a difference in the world without the corporate world? > Definitely not. If you only care about the former that's fine, but > have no illusion that we would even be having this discussion here > were it not for the corporate world caring about Linux on ARM. Maybe. But corporations so far have played by the Open Source rules to make ARM Linux what it is. There was mutual benefits in that and ARM Linux did grew faster. Having accommodations in the kernel for proprietary drivers is not a mutual benefit anymore. That might be hard to understand from your point of view, but the incentives in the Open Source communities aren't based on commercial results. Nicolas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Freescale Linux BSP review
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote: > On 22 December 2010 21:22, Nicolas Pitre wrote: > > Having accommodations in the kernel for proprietary drivers is not a > > mutual benefit anymore. That might be hard to understand from your > > point of view, but the incentives in the Open Source communities aren't > > based on commercial results. > > DISCLAIMER: I'm also a Debian developer -have been since 1999 with a > small 2y break- so I _do_ know the F/OSS community point of view. My > goals have been always in promoting open source and free software > solutions when and when not available. Good to know. > Right now open source solutions are _not_ available, and that is the > problem. Yes, everyone agrees. Well, I suppose. That would be the first official statement to make. Do we really consider this a problem? Because most companies used to the proprietary model won't see a problem at all here, and therefore wouldn't consider any effort in the direction of open drivers a worthy goal. That would be the heart of any subsequent misunderstandings. I'll let someone else with a bigger Linaro hat make that official statement though. > I haven't reversed engineered any driver so I can't claim of knowledge in this > matter. However I've been following closely other such projects like nouveau > and it took them a _long_ time to get to this point here -which may be usable > for many people, but it's not even at a beta state according to the Nouveau > developers. Even if we assume the fact that 10 times more ARM F/OSS > developers gather to reverse engineer the binary blobs, how long do you think > it would take until a beta driver appears? 1 year? 2 years? And what will > happen > in the meantime? In the mean time some other company might see a nice opportunity to sidestep the competition by making its drivers fully open source. That's what happened with WIFI, resulting in the least expected company to finally open up its driver like all the others ended up doing. It must have been economically advantageous to them in the end (lower support costs, additional customer opportunities, etc.) > I'm not advocating that closed source drivers be included in the > kernel, but IMHO, having an open kernel-space driver would also help > the reverse engineering process at the same time as allowing common > users as well as developers to use and test any 3D applications -don't > forget that 3D problems don't end at the driver, rather the opposite. Problems don't end at the driver, they start there. And those proprietary drivers exist and are being used already. But don't expect the mainline kernel to make accommodations for them. It is not economically viable for the Open Source community to accommodate proprietary drivers, irrespective of how loud you might advocate for that. Nicolas___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Freescale Linux BSP review
On Thu, 23 Dec 2010, Xavier Bestel wrote: > Le mercredi 22 décembre 2010 à 15:29 -0500, Nicolas Pitre a écrit : > > It is > > not economically viable for the Open Source community to accommodate > > proprietary drivers, irrespective of how loud you might advocate for > > that. > > I think you can remove the word "economically" from your sentence (or > replace it with e.g. "technically"), and it's all the more true. I used that word on purpose. Economic principles do exist in the Open Source world too. It is just not based on monetary profits. Nicolas___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Freescale Linux BSP review
On Wed, 22 Dec 2010, David Rusling wrote: > Now for a bit of a rant. Personally, I have a deep and abiding > respect for open source (for me, it's the key social invention of the > internet age), however I also recognise that it would not exist > without companies using open source as part of their products. Let's > face it, an awful lot of open source engineers are getting their > mortgages paid by companies that make use of open source. I cannot be in full agreement with the above statement. I think the reality is way more nuanced than that. The truth of the matter is that Open Source came into existence without and despite involvement from the corporate world. And the very reason it started to attract interest from the corporate world is because of Open Source's superior quality and performance at a lower cost. Open Source would have existed even without companies using it as you would still have those Open Source activists using it themselves in your product, even without the help of the corporate money. The company involvement in Open Source did indeed accelerate its development by paying many people to work on it full time. But Open Source would still be there and still be in good shape even if corporate involvement didn't happen, just like it was before. And this superior quality and performance characteristics of Open Source are not a coincidence. They are the first motives in a world which is not driven by monetary profits, unlike most if not all the proprietary alternatives. The people leading Open Source are driven by the technical excellence of their work and the recognition they get from their peers. Money is a far secondary motive, and in this age you can choose between different sources of sufficient money not to have to worry about it anymore and compromise too much on your primary motives when you already have a track record in this Open Source world. So to say that the corporate world might need to consider Open Source to be competitive and survive, but the reverse is not true i.e. Open Source doesn't _require_ the corporate world to survive. > No company invests in open source for philanthropic reasons; they > understand that it is necessary for their businesses. The tricky > problem is always in how ethical a company's usage is (and I use the > word 'ethical' deliberately because this is wider than mere legal > words smithing); whenever I give talks on GPL, I emphasise both the > moral as well as the legal duties. In my experience, most companies > struggle to understand open source when they first start to interact > with it. It usually takes some open source zealots within the company > to persuade their management of the right way to behave. The best way > to get companies to change their behaviour is to find them and support > them. Making threatening GPL noises in email does not help them in > any way. Here I'm more in agreement with you. However this is again not the full picture. Ethical or not, the first motive of a company is to make profits. If that was easy to get away with it, all that companies would do is simply to grab this body of source code for themselves and never contribute back. And a sizable number of companies, even some sizable companies, are doing just that. While this isn't going to kill Open Source, this certainly makes it weaker because this is contrary to that very first principle that made Open Source a success in the first place. Companies doing that are after the immediate monetary profit and not the technical excellence and performances. But even when leaving the ethical aspect aside, it is not going to be profitable for companies in the long term to grab Open Source results and move it back to the legacy proprietary model. Doing that will be to their disadvantage when some other companies come along to compete on the market using Open Source to its fullest technical excellence and performance potential. Fortunately, a sizable number of companies, even sizable ones, did understand that already. But... while some companies are struggling to understand how to interact with Open Source, the Open Source world still dash ahead without much concerns for corporate profits. As said above, those strange Open Source animals are motivated by the technical excellence of their work, and they're going to fight on that front against anything that might affect or prevent that goal. This is again why Open Source has always progressed even despite initial attempts to kill it from some corporations. So far, Linux has always been immune to monetary forces, whether those forces were against it or not. So it is fair to say that Open Source survival depends primarily on its technical advantages above anything else. In conclusion: don't get surprised if technically inferior propositions, such as proprietary 3D libraries coupled with kernel-side interfaces, are met with strong
Freescale Linux BSP review
On Wed, 22 Dec 2010, Tom Gall wrote: > The very important part of this whole discussion is getting arm Linux and it's > 3d driver situation so it TOO is the best. > > Right now it's not and pointing to other elements of the system and saying > "it's great" is besides the point. My whole point, if I may resume my conclusion to a few words, is that most Open Source folks don't care if you can't open your code for whatever reasons. That won't encourage them to compromise on their fundamental principle. It's up to those companies to balance the cost of maintaining their ad hoc proprietary stuff themselves vs the cost of opening up their code so it can be merged upstream. > This discussion is good, but for it to have a positive outcome, we need to > turn the direction back to how we get to the end goal > for arm 3D graphics. Absolutely! > It's not probably going to happen at once with one patch that does > what everyone wants. I think it's going to take graduated steps and > some compromises. Yes. However, as I said, those compromises may not come on the technical aspects of the kernel interfaces. Just like it is unlikely for companies to ever compromise on their profits. Any compromise touching any of those fundamental aspects for their respective parties is bound to always fail. In other words, let's save ourselves some energy and give up on the idea that a kernel shim only for a binary only user space library is going to ever be accepted in mainline. This simply will never happen, period. Nicolas
Freescale Linux BSP review
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote: > On 22 December 2010 20:39, Piotr Gluszenia Slawinski > wrote: > >> So to say that the corporate world might need to consider Open Source to > >> be competitive and survive, but the reverse is not true i.e. Open Source > >> doesn't _require_ the corporate world to survive. > > > > i agree with it fully, and to support this claim i want to remind the > > simple rule of capital accumulation. Open Source community > > _already_ accumulated enough _capital_ in form of algorithms, > > implementations, social relations, experience, documentation and > > augmentation with education system . > > I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually > thrive and make a difference in the world without the corporate world? > Definitely not. If you only care about the former that's fine, but > have no illusion that we would even be having this discussion here > were it not for the corporate world caring about Linux on ARM. Maybe. But corporations so far have played by the Open Source rules to make ARM Linux what it is. There was mutual benefits in that and ARM Linux did grew faster. Having accommodations in the kernel for proprietary drivers is not a mutual benefit anymore. That might be hard to understand from your point of view, but the incentives in the Open Source communities aren't based on commercial results. Nicolas
Freescale Linux BSP review
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote: > On 22 December 2010 21:22, Nicolas Pitre wrote: > > Having accommodations in the kernel for proprietary drivers is not a > > mutual benefit anymore. ?That might be hard to understand from your > > point of view, but the incentives in the Open Source communities aren't > > based on commercial results. > > DISCLAIMER: I'm also a Debian developer -have been since 1999 with a > small 2y break- so I _do_ know the F/OSS community point of view. My > goals have been always in promoting open source and free software > solutions when and when not available. Good to know. > Right now open source solutions are _not_ available, and that is the > problem. Yes, everyone agrees. Well, I suppose. That would be the first official statement to make. Do we really consider this a problem? Because most companies used to the proprietary model won't see a problem at all here, and therefore wouldn't consider any effort in the direction of open drivers a worthy goal. That would be the heart of any subsequent misunderstandings. I'll let someone else with a bigger Linaro hat make that official statement though. > I haven't reversed engineered any driver so I can't claim of knowledge in this > matter. However I've been following closely other such projects like nouveau > and it took them a _long_ time to get to this point here -which may be usable > for many people, but it's not even at a beta state according to the Nouveau > developers. Even if we assume the fact that 10 times more ARM F/OSS > developers gather to reverse engineer the binary blobs, how long do you think > it would take until a beta driver appears? 1 year? 2 years? And what will > happen > in the meantime? In the mean time some other company might see a nice opportunity to sidestep the competition by making its drivers fully open source. That's what happened with WIFI, resulting in the least expected company to finally open up its driver like all the others ended up doing. It must have been economically advantageous to them in the end (lower support costs, additional customer opportunities, etc.) > I'm not advocating that closed source drivers be included in the > kernel, but IMHO, having an open kernel-space driver would also help > the reverse engineering process at the same time as allowing common > users as well as developers to use and test any 3D applications -don't > forget that 3D problems don't end at the driver, rather the opposite. Problems don't end at the driver, they start there. And those proprietary drivers exist and are being used already. But don't expect the mainline kernel to make accommodations for them. It is not economically viable for the Open Source community to accommodate proprietary drivers, irrespective of how loud you might advocate for that. Nicolas
Freescale Linux BSP review
On Thu, 23 Dec 2010, Xavier Bestel wrote: > Le mercredi 22 d?cembre 2010 ? 15:29 -0500, Nicolas Pitre a ?crit : > > It is > > not economically viable for the Open Source community to accommodate > > proprietary drivers, irrespective of how loud you might advocate for > > that. > > I think you can remove the word "economically" from your sentence (or > replace it with e.g. "technically"), and it's all the more true. I used that word on purpose. Economic principles do exist in the Open Source world too. It is just not based on monetary profits. Nicolas
[PATCH] ARM: add get_user() support for 8 byte types
On Thu, 15 Nov 2012, Rob Clark wrote:
> From: Rob Clark
>
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).
>
> v1: original
> v2: pass correct size to check_uaccess, and better handling of narrowing
> double word read with __get_user_xb() (Russell King's suggestion)
> v3: explain in comment about why this works for narrowing fetch to 1,
> 2, or 4 byte type on ARM.
>
> Signed-off-by: Rob Clark
Acked-by: Nicolas Pitre
> ---
> arch/arm/include/asm/uaccess.h | 22 +-
> arch/arm/lib/getuser.S | 17 -
> 2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
> index 7e1f760..4cfa793 100644
> --- a/arch/arm/include/asm/uaccess.h
> +++ b/arch/arm/include/asm/uaccess.h
> @@ -100,6 +100,7 @@ static inline void set_fs(mm_segment_t fs)
> extern int __get_user_1(void *);
> extern int __get_user_2(void *);
> extern int __get_user_4(void *);
> +extern int __get_user_8(void *);
>
> #define __GUP_CLOBBER_1 "lr", "cc"
> #ifdef CONFIG_CPU_USE_DOMAINS
> @@ -108,6 +109,7 @@ extern int __get_user_4(void *);
> #define __GUP_CLOBBER_2 "lr", "cc"
> #endif
> #define __GUP_CLOBBER_4 "lr", "cc"
> +#define __GUP_CLOBBER_8 "lr", "cc"
>
> #define __get_user_x(__r2,__p,__e,__l,__s) \
> __asm__ __volatile__ ( \
> @@ -118,11 +120,23 @@ extern int __get_user_4(void *);
> : "0" (__p), "r" (__l) \
> : __GUP_CLOBBER_##__s)
>
> +/*
> + * Narrowing a double-word get into a single 32bit word register, which works
> + * for 1, 2, or 4 byte types on ARM because there are no integer registers
> + * smaller than 32bit
> + */
> +#ifdef BIG_ENDIAN
> +#define __get_user_xb(__r2,__p,__e,__l,__s) \
> + __get_user_x(__r2,(uintptr_t)__p + 4,__e,__l,__s)
> +#else
> +#define __get_user_xb __get_user_x
> +#endif
> +
> #define __get_user_check(x,p)
> \
> ({ \
> unsigned long __limit = current_thread_info()->addr_limit - 1; \
> register const typeof(*(p)) __user *__p asm("r0") = (p);\
> - register unsigned long __r2 asm("r2"); \
> + register typeof(x) __r2 asm("r2"); \
> register unsigned long __l asm("r1") = __limit; \
> register int __e asm("r0"); \
> switch (sizeof(*(__p))) { \
> @@ -135,6 +149,12 @@ extern int __get_user_4(void *);
> case 4: \
> __get_user_x(__r2, __p, __e, __l, 4); \
> break; \
> + case 8: \
> + if (sizeof((x)) < 8)\
> + __get_user_xb(__r2, __p, __e, __l, 4); \
> + else\
> + __get_user_x(__r2, __p, __e, __l, 8); \
> + break; \
> default: __e = __get_user_bad(); break; \
> } \
> x = (typeof(*(p))) __r2;\
> diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
> index 9b06bb4..ed98707 100644
> --- a/arch/arm/lib/getuser.S
> +++ b/arch/arm/lib/getuser.S
> @@ -18,7 +18,7 @@
> * Inputs: r0 contains the address
> * r1 contains the address limit, which must be preserved
> * Outputs: r0 is the error code
> - * r2 contains the zero-extended value
> + * r2, r3 contains the zero-extended value
> * lr corrupted
> *
> * No other registers must be altered. (see
> @@ -66,6 +66,19 @@ ENTRY(__get_user_4)
> mov pc, lr
> ENDPROC(__get_user_4)
>
> +ENTRY(__get_user_8)
> + check_uaccess r0, 8, r1, r2, __get_user_bad
> +#ifdef CONFIG_THUMB2_KERNEL
> +5: TUSER(ldr)r2, [r0]
> +6: TUSER(ldr)r3, [r0, #4
