Fwd: FYI: OpenID auth disabled on android-build.linaro.org
Hello, OpenID plugin usage has been disabled in ci.linaro.org due to some vulnerability detected with the plugin. Hence the Single Sig On option using your launchpad id wont work for now till it gets fixed. If you need to use ci.linaro.org services and need a way to login please create a new user on ci.linaro.org and mail me the details and I will give you appropriate access to the service. -- Forwarded message -- From: Paul Sokolovsky Date: Fri, Oct 28, 2011 at 4:09 PM Subject: FYI: OpenID auth disabled on android-build.linaro.org To: linaro-android , Alexander Sack < a...@linaro.org>, Danilo Šegan , Infrastructure < infrastruct...@linaro.org> Hello, Due to suspected security issue, OpenID auth was disabed on android-build.linaro.org. OpenID was never recommended as auth means there, and instead username/passwd auth was recommended, so this change should not affect users. Please let me know if you have any issues. ETA for being enabled back is so far not known, Danilo Shegan tracks this issue. -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- Thanks and Regards, Deepti Infrastructure Team Member, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: FYI: OpenID auth disabled on android-build.linaro.org
Thanks for this info Deepti. I'm assuming this is the same reason I had issues logging into the summit scheduler. ~Deepak On 31 October 2011 03:42, Deepti Kalakeri wrote: > Hello, > > OpenID plugin usage has been disabled in ci.linaro.org due to some > vulnerability detected with the plugin. > Hence the Single Sig On option using your launchpad id wont work for now > till it gets fixed. > If you need to use ci.linaro.org services and need a way to login please > create a new user on ci.linaro.org > and mail me the details and I will give you appropriate access to the > service. > > -- Forwarded message -- > From: Paul Sokolovsky > Date: Fri, Oct 28, 2011 at 4:09 PM > Subject: FYI: OpenID auth disabled on android-build.linaro.org > To: linaro-android , Alexander Sack > , Danilo Šegan , Infrastructure > > > > Hello, > > Due to suspected security issue, OpenID auth was disabed on > android-build.linaro.org. OpenID was never recommended as auth means > there, and instead username/passwd auth was recommended, so this change > should not affect users. Please let me know if you have any issues. > > ETA for being enabled back is so far not known, Danilo Shegan tracks > this issue. > > -- > Best Regards, > Paul > > Linaro.org | Open source software for ARM SoCs > Follow Linaro: http://www.facebook.com/pages/Linaro > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog > > > > -- > Thanks and Regards, > Deepti > Infrastructure Team Member, Linaro Platform Teams > Linaro.org | Open source software for ARM SoCs > Follow Linaro: http://www.facebook.com/pages/Linaro > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog > > > ___ > linaro-kernel mailing list > linaro-ker...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-kernel > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 1/4] ARM: Exynos4: Add thermal sensor driver for samsung exynos4 platform.
On 27 October 2011 04:08, Kyungmin Park wrote:
> Hi,
>
> exynos4 tmu is already merged 3.2-rc
> you can find it at below message and latest git kernel
> http://www.spinics.net/lists/lm-sensors/msg33872.html
>
> Thank you,
> Kyungmin Park
ok I will rebase my work on top of sensor
Thanks for pointing this out.
>
> On Wed, Oct 26, 2011 at 8:36 PM, Amit Daniel Kachhap
> wrote:
>> This patch adds support for thermal sensor driver. It supports 3 trigger
>> level. The first 2 level are warn and monitor temperature level. The
>> third critical trigger level resets the system. The threshold
>> change information is sent to the thermal interface layer.
>>
>> Signed-off-by: SangWook Ju
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> arch/arm/mach-exynos4/include/mach/exynos4-tmu.h | 75
>> drivers/staging/Kconfig | 2 +
>> drivers/staging/Makefile | 1 +
>> drivers/staging/thermal_exynos4/sensor/Kconfig | 14 +
>> drivers/staging/thermal_exynos4/sensor/Makefile | 4 +
>> .../thermal_exynos4/sensor/exynos4210_tmu.c | 465
>>
>> 6 files changed, 561 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
>> create mode 100644 drivers/staging/thermal_exynos4/sensor/Kconfig
>> create mode 100644 drivers/staging/thermal_exynos4/sensor/Makefile
>> create mode 100644 drivers/staging/thermal_exynos4/sensor/exynos4210_tmu.c
>>
>> diff --git a/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
>> b/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
>> new file mode 100644
>> index 000..dc7bf37
>> --- /dev/null
>> +++ b/arch/arm/mach-exynos4/include/mach/exynos4-tmu.h
>> @@ -0,0 +1,75 @@
>> +/**
>> + * exynos4-tmu.h - definitions of exynos4 specific thermal interface
>> + *
>> + * Copyright (C) 2011 Samsung Electronics Co. ltd.
>> +
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> +
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> +
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>> + */
>> +
>> +#ifndef _EXYNOS4_TMU_H
>> +#define _EXYNOS4_TMU_H
>> +
>> +/**
>> + * tmu_data - tmu driver private structure
>> + * @t1: colling stop temperature.
>> + * @dc_temp: Temperature base.
>> + * @init_threshold: Initial threshold temperature.
>> + * @mode: Compensation mode.
>> + * @comp_threshold: compensated threshold temperature.
>> + *
>> + */
>> +struct tmu_data {
>> + char te1;
>> + char te2;
>> + unsigned int init_threshold;
>> + int mode;
>> + int cooling;
>> + unsigned int comp_threshold;
>> + int tmu_flag;
>> +};
>> +
>> +/**
>> + * tmu_platform_device - tmu platform specific structure
>> + * @id: Device id.
>> + * @tmu_base: Memory register base.
>> + * @dev: TMU device.
>> + * @data: TMU driver private data structure.
>> + *
>> + */
>> +struct tmu_platform_device {
>> + int id;
>> + struct platform_device *pdev;
>> + void __iomem *tmu_base;
>> + struct device *dev;
>> + struct tmu_data data;
>> + struct thermal_dev *therm_fw;
>> +};
>> +
>> +#ifdef CONFIG_PM
>> +struct exynos4_tmu_register {
>> + unsigned int regval_thresh_temp;
>> + unsigned int regval_trig_lev0;
>> + unsigned int regval_trig_lev1;
>> + unsigned int regval_trig_lev2;
>> + unsigned int regval_trig_lev3;
>> + unsigned int regval_tmu_con0;
>> + unsigned int regval_int_en;
>> +};
>> +#endif
>> +
>> +extern void exynos4_tmu_set_platdata(struct tmu_data *pd);
>> +extern struct tmu_platform_device *exynos4_tmu_get_platdata(void);
>> +extern int exynos4_tmu_get_irqno(int num);
>> +#endif /* _EXYNOS4_TMU_H */
>> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
>> index 2582e18..4376fed 100644
>> --- a/drivers/staging/Kconfig
>> +++ b/drivers/staging/Kconfig
>> @@ -148,4 +148,6 @@ source "drivers/staging/mei/Kconfig"
>>
>> source "drivers/staging/nvec/Kconfig"
>>
>> +source "drivers/staging/thermal_exynos4/Kconfig"
>> +
>> endif # STAGING
>> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
>> index 50d112f..24a2943 100644
>> --- a/drivers/staging/Makefile
>> +++ b/drivers/staging/Makefile
>> @@ -65,3 +65,4 @@ obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4) += ste_rmi4/
>> o
Re: Proposal for a low-level Linux display framework
On Sat, 17 Sep 2011 21:25:29 +0100 Alan Cox wrote: > > Just tell the X driver to not use acceleration, and it you won't get > > any acceleration used, then you get complete stability. If a driver > > writer wants to turn off all accel in the kernel driver, it can, its > > In fact one thing we actually need really is a "dumb" KMS X server to > replace the fbdev X server that unaccel stuff depends upon and which > can't do proper mode handling, multi-head or resizing as a result. A dumb > fb generic request for a back to front copy might also be useful for > shadowfb, or at least indicators so you know what the cache behaviour is > so the X server can pick the right policy. > > > We've fixed this in KMS, we don't pass direct mappings to userspace > > that we can't tear down and refault. We only provide objects via > > handles. The only place its a problem is where we expose fbdev legacy > > emulation, since we have to fix the pages. > > Which is doable. Horrible but doable. The usb framebuffer code has to > play games like this with the virtual framebuffer in order to track > changes by faulting. > > There are still some architectural screwups however. DRM continues the > fbdev worldview that outputs, memory and accelerators are tied together > in lumps we call video cards. That isn't really true for all cases and > with capture/overlay it gets even less true. Sorry for re-opening this ancient thread; I'm catching up from the past 2 months of travel & misc. I definitely agree about the PC card centric architecture of DRM KMS (and before it, X). But we have a path out of it now, and lots of interest from vendors and developers, so I don't think it's an insurmountable problem by any means. I definitely understand Florian's worries about DRM vs fb. If nothing else, there's certainly a perception that fb is simpler and easier to get right. But really, as others have pointed out, it's solving a different set of problems than the DRM layer. The latter is actually trying to expose the features of contemporary hardware in a way that's as portable as possible. That portability comes at a cost though: the APIs we add need to get lots of review, and there's no doubt we'll need to add more as newer, weirder hardware comes along. Really, I see no reason why fb and DRM can't continue to live side by side. If a vendor really only needs the features provided by the fb layer, they're free to stick with a simple fb driver. However, I expect most vendors making phones, tablets, notebooks, etc will need and want an architecture that looks a lot like the DRM layer, with authentication for rendering clients, an command submission ioctl for acceleration, and memory management, so I expect most of the driver growth to be in DRM in the near future. And I totally agree with Dave about having a kmscon. I really wish someone would implement it so I could have my VTs spinning on a cube. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
