* Re: pvops Dom0 graphics doesnt work with Intel i915
From: sanjay kushwaha @ 2010-10-07 22:44 UTC (permalink / raw)
To: Kay, Allen M; +Cc: Jeremy Fitzhardinge, xen-devel, Konrad Rzeszutek Wilk
In-Reply-To: <987664A83D2D224EAE907B061CE93D530163EA9530@orsmsx505.amr.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 11775 bytes --]
Hi Allen,
Indeed I needed this workaround. Now graphics works fine with VT-d with this
xen tree.
Thanks,
Sanjay
On Thu, Oct 7, 2010 at 3:05 PM, Kay, Allen M <allen.m.kay@intel.com> wrote:
> Sanjay,
>
>
>
> Have you tried the latest xen-unstable staging tree? It has a workaround
> for T410 VT-d graphics issue caused by Lenovo BIOS. This might be the
> workaround you need:
>
>
>
> http://xenbits.xensource.com/staging/xen-unstable.hg?rev/4beee5779122
>
>
>
> Allen
>
>
>
> *From:* xen-devel-bounces@lists.xensource.com [mailto:
> xen-devel-bounces@lists.xensource.com] *On Behalf Of *sanjay kushwaha
> *Sent:* Thursday, October 07, 2010 12:13 PM
> *To:* Konrad Rzeszutek Wilk
> *Cc:* Jeremy Fitzhardinge; xen-devel
> *Subject:* Re: [Xen-devel] pvops Dom0 graphics doesnt work with Intel i915
>
>
>
> Hi Konrad,
> Unfortunately T410 doesnt have a serial port and neither does the docking
> station. I havent had any success with USB-to-Serial port dongles in the
> past. is there any way to get the serial port output?
>
> Thanks,
> Sanjay
>
> On Thu, Oct 7, 2010 at 11:05 AM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
>
> On Thu, Oct 07, 2010 at 10:36:34AM -0700, sanjay kushwaha wrote:
> > Hi Konrad,
> > I tried your tree. It created a 2.6.32.15 based pvops kernel but graphics
> > with VT-d still doesn't work. when I give iommu=0 on xen kernel command
> line
> > in grub menu, graphics works but with iommu=1 it doesnt work (The whole
> > screen is garbage).
>
> Are there any warnings/debug messages in the serial log? Please follow
> the PVOPS Wiki on how to enable all the debug options.
>
> >
> >
> > On Wed, Oct 6, 2010 at 6:07 PM, Konrad Rzeszutek Wilk <
> > konrad.wilk@oracle.com> wrote:
> >
> > > On Wed, Oct 06, 2010 at 04:02:51PM -0700, sanjay kushwaha wrote:
> > > > Thanks Pasi.
> > > >
> > > > Hi Konrad,
> > > > Could you please let me know how to get these backported drivers as
> > > > indicated by Pasi? This is the tree that I have.
> > >
> > > Just follow the Wiki. Oh, I need to update it.
> > >
> > > Here do this:
> > >
> > > git remote add konrad git://
> > > git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > >
> > > git pull konrad
> > > git checkout konrad/devel/next.drm
> > >
> > > make
> > >
> > > >
> > > > [evans@vwifi0 linux-2.6.32.x]$ git show
> > > > commit b297cdac0373625d3cd0e6f2b393570dcf2edba6
> > > > Merge: c6cfd01 64392f6
> > > > Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > > > Date: Mon Sep 13 14:27:24 2010 -0700
> > > >
> > > > Merge branch 'xen/next' into xen/next-2.6.32
> > > >
> > > > * xen/next:
> > > > xen/netfront: Fix another potential race condition
> > > > Revert "xen/netfront: default smartpoll to on"
> > > >
> > > > [evans@vwifi0 linux-2.6.32.x]$
> > > >
> > > >
> > > > Thanks,
> > > > Sanjay
> > > >
> > > > On Wed, Oct 6, 2010 at 1:12 PM, Pasi Kärkkäinen <pasik@iki.fi>
> wrote:
> > > >
> > > > > On Wed, Oct 06, 2010 at 10:50:57AM -0700, sanjay kushwaha wrote:
> > > > > > Hi,
> > > > > > I have run into more problems now. This time with VT-d.
> > > > > > When I enable VT-d on this laptop, graphics again stops
> working in
> > > > > dom0
> > > > > > with pvops (linux 2.6.32.21). the screen starts showing
> garbage as
> > > > > soon as
> > > > > > it switches into graphics mode.this happens when I boot the
> pvops
> > > > > kernel
> > > > > > both as dom0 and native linux. However, when I try 2.6.33
> based
> > > pvops
> > > > > > kernel (stable-2.6.33.x) graphics seems to work fine with VT-d
> > > when
> > > > > > running native but it doesnt work when running as Dom0.
> > > > > >
> > > > > > so now the problem is:
> > > > > >
> > > > > > with stable-2.6.32.x: graphics works in Dom0 without Vt-d but
> not
> > > with
> > > > > > VT-d (neither native nor Dom0).
> > > > > > with stable-2.6.33.x: graphics works with VT-d when running
> native
> > > but
> > > > > > doesnt work when running as Dom0 (with or without VT-d).
> > > > > >
> > > > >
> > > > > stable-2.6.33.x is not maintained, and you shouldn't use it.
> > > > >
> > > > > I think Konrad has a backport of the 2.6.34 drm/dri drivers
> > > > > to stable-2.6.32.x somewhere.. that might help.
> > > > >
> > > > > http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> > > > >
> > > > > -- Pasi
> > > > >
> > > > > > I am experiencing this problem both with Lenovo T410, and Dell
> > > > > latitude
> > > > > > E6410.
> > > > > > Has anybody experienced this problem?
> > > > > >
> > > > > > Thanks,
> > > > > > Sanjay
> > > > > >
> > > > > > On Fri, Oct 1, 2010 at 11:06 AM, sanjay kushwaha
> > > > > > <[1]sanjay.kushwaha@gmail.com> wrote:
> > > > > >
> > > > > > havent tried stable-2.6.32.x on Radeon. It works with
> nomodeset
> > > and
> > > > > > nopat options with stable-2.6.33.x branch.
> > > > > >
> > > > > > On Fri, Oct 1, 2010 at 10:57 AM, Konrad Rzeszutek Wilk
> > > > > > <[2]konrad.wilk@oracle.com> wrote:
> > > > > >
> > > > > > On Fri, Oct 01, 2010 at 10:06:48AM -0700, sanjay kushwaha
> > > wrote:
> > > > > > > When I dont use nomodeset option, dom0 boots fine X runs
> > > > > properly.
> > > > > > So Fedora
> > > > > > > 13 (X86_64) distro with stable-2.6.32.x pvops kernel and
> > > > > > xen-unstable works
> > > > > > > fine for i915 without nomodeset option.
> > > > > >
> > > > > > Good to hear it works for you.
> > > > > >
> > > > > > What about your radeon laptop?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Sanjay
> > > > > > >
> > > > > > > On Wed, Sep 29, 2010 at 3:56 PM, sanjay kushwaha
> > > > > > > <[3]sanjay.kushwaha@gmail.com>wrote:
> > > > > > >
> > > > > > > > Hi Jeremy,
> > > > > > > > I switched to stable-2.6.32.x branch (which is
> 2.6.32.21
> > > > > based)
> > > > > > but I get
> > > > > > > > the same problem. Attached is the Xorg.0.log file when
> I
> > > > > booted
> > > > > > with
> > > > > > > > nomodeset option.
> > > > > > > >
> > > > > > > > interestingly I did not see any kernel or driver crash
> > > > > messages in
> > > > > > the
> > > > > > > > dmesg output. I do see these messages multiple times
> in
> > > > > > /var/log/messages
> > > > > > > > *
> > > > > > > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > > GdmDisplay:
> > > > > > display
> > > > > > > > lasted 0.048984 seconds
> > > > > > > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > > > > > GdmLocalDisplayFactory:
> > > > > > > > maximum number of X display failures reached: check X
> > > server
> > > > > log
> > > > > > for errors
> > > > > > > > *
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Sanjay
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Sep 29, 2010 at 11:57 AM, Jeremy Fitzhardinge
> > > > > > <[4]jeremy@goop.org>wrote:
> > > > > > > >
> > > > > > > >> On 09/29/2010 11:12 AM, sanjay kushwaha wrote:
> > > > > > > >> > Hi Folks,
> > > > > > > >> > I am trying to boot latest xen-unstable on my
> laptop
> > > which
> > > > > has
> > > > > > Intel
> > > > > > > >> > i915 graphics. PVOPS dom0 is 2.6.33.6 based (from
> > > branch
> > > > > > > >> > xen/stable-2.6.33.x)
> > > > > > > >>
> > > > > > > >> Don't use that branch; it isn't supported (in fact, I
> > > deleted
> > > > > it
> > > > > > a while
> > > > > > > >> ago). Use xen/stable-2.6.32.x for now.
> > > > > > > >>
> > > > > > > >> J
> > > > > > > >>
> > > > > > > >> > and the distro is fedora 13 64-bit. The graphics
> doesnt
> > > > > come up
> > > > > > and it
> > > > > > > >> > seems that i915 driver is crashing multiple times.
> If I
> > > > > boot in
> > > > > > > >> > run-level 3 (without X) dom0 boots fine.
> > > > > > > >> > I tried booting the dom0 kernel with nomodeset and
> > > nopat
> > > > > > options
> > > > > > > >> > without any success. I searched on internet and
> found
> > > that
> > > > > > multiple
> > > > > > > >> > people have reported similar problem but I could
> not
> > > find
> > > > > any
> > > > > > solution.
> > > > > > > >> >
> > > > > > > >> > Has anybody found a solution or workaround to this
> > > problem?
> > > > > > > >> >
> > > > > > > >> > Thanks,
> > > > > > > >> > Sanjay
> > > > > > > >> >
> > > > > > > >> > PS: I have another laptop with same version of xen
> and
> > > > > pvops
> > > > > > dom0 but
> > > > > > > >> > it has ATI radeon graphics card. This laptop boots
> dom0
> > > > > with
> > > > > > graphics
> > > > > > > >> > when I give nomodeset and nopat options (but fails
> if I
> > > > > dont
> > > > > > give
> > > > > > > >> > either of those two options).
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > _______________________________________________
> > > > > > > >> > Xen-devel mailing list
> > > > > > > >> > [5]Xen-devel@lists.xensource.com
> > > > > > > >> > [6]http://lists.xensource.com/xen-devel
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > >
> > > > > > > _______________________________________________
> > > > > > > Xen-devel mailing list
> > > > > > > [7]Xen-devel@lists.xensource.com
> > > > > > > [8]http://lists.xensource.com/xen-devel
> > > > > >
> > > > > > --
> > > > > > ----------------------
> > > > > > Dr. Sanjay Kumar
> > > > > > Research Scientist
> > > > > > Intel Corporation
> > > > > >
> > > > > > --
> > > > > > ----------------------
> > > > > > Dr. Sanjay Kumar
> > > > > > Research Scientist
> > > > > > Intel Corporation
> > > > > >
> > > > > > References
> > > > > >
> > > > > > Visible links
> > > > > > 1. mailto:sanjay.kushwaha@gmail.com
> > > > > > 2. mailto:konrad.wilk@oracle.com
> > > > > > 3. mailto:sanjay.kushwaha@gmail.com
> > > > > > 4. mailto:jeremy@goop.org
> > > > > > 5. mailto:Xen-devel@lists.xensource.com
> > > > > > 6. http://lists.xensource.com/xen-devel
> > > > > > 7. mailto:Xen-devel@lists.xensource.com
> > > > > > 8. http://lists.xensource.com/xen-devel
> > > > >
> > > > > > _______________________________________________
> > > > > > Xen-devel mailing list
> > > > > > Xen-devel@lists.xensource.com
> > > > > > http://lists.xensource.com/xen-devel
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ----------------------
> > > > Dr. Sanjay Kumar
> > > > Research Scientist
> > > > Intel Corporation
> > >
> >
> >
> >
> > --
> > ----------------------
> > Dr. Sanjay Kumar
> > Research Scientist
> > Intel Corporation
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>
>
>
> --
> ----------------------
> Dr. Sanjay Kumar
> Research Scientist
> Intel Corporation
>
--
----------------------
Dr. Sanjay Kumar
Research Scientist
Intel Corporation
[-- Attachment #1.2: Type: text/html, Size: 19961 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* + namespaces-remove-pid_ns-and-net_ns-experimental-status.patch added to -mm tree
From: akpm @ 2010-10-07 22:44 UTC (permalink / raw)
To: mm-commits; +Cc: daniel.lezcano, davem, ebiederm
The patch titled
namespaces: remove pid_ns and net_ns experimental status
has been added to the -mm tree. Its filename is
namespaces-remove-pid_ns-and-net_ns-experimental-status.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: namespaces: remove pid_ns and net_ns experimental status
From: Daniel Lezcano <daniel.lezcano@free.fr>
The pid namespace is in the kernel since 2.6.27 and the net_ns since
2.6.29. They are enabled in the distro by default and used by userspace
component. They are mature enough to remove the 'experimental' label.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
init/Kconfig | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff -puN init/Kconfig~namespaces-remove-pid_ns-and-net_ns-experimental-status init/Kconfig
--- a/init/Kconfig~namespaces-remove-pid_ns-and-net_ns-experimental-status
+++ a/init/Kconfig
@@ -759,21 +759,18 @@ config USER_NS
If unsure, say N.
config PID_NS
- bool "PID Namespaces (EXPERIMENTAL)"
+ bool "PID Namespaces"
default n
- depends on NAMESPACES && EXPERIMENTAL
+ depends on NAMESPACES
help
Support process id namespaces. This allows having multiple
processes with the same pid as long as they are in different
pid namespaces. This is a building block of containers.
- Unless you want to work with an experimental feature
- say N here.
^ permalink raw reply
* Drivers for ISDB-T | Drivers para o Sistema Brasileiro de Televisão
From: Mauro Carvalho Chehab @ 2010-10-07 22:45 UTC (permalink / raw)
To: Linux Media Mailing List
PS.: This email will probably be more useful for Brazilians and other people at
Latin America. So, I'll write it in Portuguese. It basically says that 5 families
of ISDB-T devices are now supported on my tree ( http://git.linuxtv.org/mchehab/sbtvd.git),
including 3 experimental ones. I'm not sure if the new drivers work in Japan. So,
feedbacks are appreciated.
---
Prezados,
Estive trabalhando no meu tempo livre com alguns cartões novos que recebi. Agradeço
a todos aqueles que nos tem ajudado, colocando estes cartões à nossa disposição.
Basicamente, estou adicionando, em caráter experimental, o suporte a 3 dispositivos
que trabalhei recentemente, capazes de receber sinais digitais no padrão SBTVD -
Sistema Brasileiro de Televisão Digital - dentro do Linux. São todos drivers abertos,
ainda experimentais. Agradecemos retorno quanto a problemas em seu funcionamento.
Todos os drivers para esses dispositivos estão em:
http://git.linuxtv.org/mchehab/sbtvd.git
Na medida em que conseguirmos colocar suporte para novos drivers, eu colocarei os
novos patches na árvore acima. Como de praxe, todos os drivers serão incorporados
na minha árvore principal, à medida em que estiverem 100%, para serem incorporados
nos novos kernels.
Com isso, temos suporte a 5 famílias de dispositivos:
1) Dibcom 0700 + DibCom 807x/809x:
Full-Seg - ou seja: pega canais HD, SD e LD;
driver dib0700. Nos meus testes, está funcionando 100%
Dispositivo testado: Pixelview SBTVD.
Driver: dib0700
2) Siano 11xx:
1Seg - pega apenas canais de baixa resolução (LD)
Também funciona 100%
O controle remoto funciona apenas na árvore de desenvolvimento.
Creio que os patches para o IR estão também na árvore do Linus. Ou seja,
devem estar funcionando à partir do kernel 2.6.36.
Dispositivo testado: Hauppauge WinTV MiniStick.
Driver: smsusb
3) Empiatech em28xx + Sharp VA3A5JZ921 (etiquetado como S.921 no chip):
1Seg - pega apenas canais de baixa resolução (LD)
Nos meus testes, conseguimos detectar os canais corretamente. No entanto,
o frontend requer sinais muito fortes. Por conta disso, não consegui
efetivamente pegar nenhum canal por aqui, embora ache que ele esteja
funcionando. Assim, aguardo testes para verificar se está 100%.
Como não possuo documentação alguma, o driver do frontend basicamente
repete a inicialização feita no driver original.
Dispositivo testado: Leadership ISDB-T.
Driver: em28xx
4) Conexant cx23102 + Fujitsu MB86A20S
Full-Seg - ou seja: pega canais HD, SD e LD;
Também funciona em modo analógico.
O driver para o frontend também repete a inicialização feita no driver
original. Nos meus testes, peguei os dois canais disponíveis em minha
localidade, tanto em 1seg quanto em fullseg.
Ainda faltam implementar algumas coisas, tais como controle remoto.
Não testei ainda as entradas S-Video/Composite.
Dispositivo: Pixelview SBTVD Hybrid.
Driver: cx231xx
5) NXP TDA7135 + Fujitsu MB86A20S;
Full-Seg - ou seja: pega canais HD, SD e LD;
A placa suporta TV analógica. No entanto, a parte analógica ainda não funciona.
O driver para o frontend é o mesmo do tipo anterior.
Ainda falta implementar controle remoto, S-Video/Composite e TV analógica.
Dispositivo: Kworld PCI SBTVD/ISDB-T Hybrid.
Driver: saa7134
Todos os dispositivos conhecidos são auto-detectados.
Para uso, basta seguir as instruções abaixo:
Instalar git e rodar os comandos:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb
cd v4l-dvb
git remote add media git://linuxtv.org/mchehab/sbtvd.git
git remote update
git checkout -b sbtvd media/sbtvd
make oldconfig
make
make modules_install install
O make oldconfig irá perguntar quais drivers novos você deseja compilar. Não esqueça de
solicitar que ele compile os drivers novos do video4linux/DVB. A dificuldade desse passo
depende da distribuição que você tem. Quanto mais próxima ela for da última versão do
kernel, menos perguntas serão feitas ;) Por favor, evitem enviar-me perguntas relacionadas
a compilação do kernel. Eu dificilmente terei tempo para respondê-las, ou poderei ajudar
muito, visto que a seleção de alguns drivers e parametros depende grandemente da distribuição
que você usa (no meu caso, eu uso o RHEL 6 beta).
O Douglas escreveu um tutorial sobre como usar dispositivos SBTVD:
http://br-linux.org/2009/sbtvd-assistindo-tv-digital-aberta-brasileira-com-o-vlc-no-linux/
O uso independe do tipo de cartão. Apenas lembre-se que canais HD e SD não serão exibidos
em dispositivos 1-Seg (embora ele detete a existência de canais HD/SD).
Por favor, reportem-me casos de sucesso nesses dispositivos, e/ou eventuais necessidades de
ajuste.
Qualquer coisa, estamos à disposição.
Abraços,
Mauro
^ permalink raw reply
* + namespaces-default-all-the-namespaces-to-yes-when-config_namespaces-is-selected.patch added to -mm tree
From: akpm @ 2010-10-07 22:45 UTC (permalink / raw)
To: mm-commits; +Cc: daniel.lezcano, davem, ebiederm
The patch titled
namespaces: default all the namespaces to 'yes' when CONFIG_NAMESPACES is selected
has been added to the -mm tree. Its filename is
namespaces-default-all-the-namespaces-to-yes-when-config_namespaces-is-selected.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: namespaces: default all the namespaces to 'yes' when CONFIG_NAMESPACES is selected
From: Daniel Lezcano <daniel.lezcano@free.fr>
As the different namespaces depend on 'CONFIG_NAMESPACES', it is logical
to enable all the namespaces when we enable NAMESPACES.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
init/Kconfig | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff -puN init/Kconfig~namespaces-default-all-the-namespaces-to-yes-when-config_namespaces-is-selected init/Kconfig
--- a/init/Kconfig~namespaces-default-all-the-namespaces-to-yes-when-config_namespaces-is-selected
+++ a/init/Kconfig
@@ -739,6 +739,7 @@ config NAMESPACES
config UTS_NS
bool "UTS namespace"
depends on NAMESPACES
+ default y
help
In this namespace tasks see different info provided with the
uname() system call
@@ -746,6 +747,7 @@ config UTS_NS
config IPC_NS
bool "IPC namespace"
depends on NAMESPACES && (SYSVIPC || POSIX_MQUEUE)
+ default y
help
In this namespace tasks work with IPC ids which correspond to
different IPC objects in different namespaces.
@@ -753,6 +755,7 @@ config IPC_NS
config USER_NS
bool "User namespace (EXPERIMENTAL)"
depends on NAMESPACES && EXPERIMENTAL
+ default y
help
This allows containers, i.e. vservers, to use user namespaces
to provide different user info for different servers.
@@ -760,8 +763,8 @@ config USER_NS
config PID_NS
bool "PID Namespaces"
- default n
depends on NAMESPACES
+ default y
help
Support process id namespaces. This allows having multiple
processes with the same pid as long as they are in different
@@ -769,8 +772,8 @@ config PID_NS
config NET_NS
bool "Network namespace"
- default n
depends on NAMESPACES && NET
+ default y
help
Allow user space to create what appear to be multiple instances
of the network stack.
_
Patches currently in -mm which might be from daniel.lezcano@free.fr are
linux-next.patch
cgroup-add-clone_children-control-file.patch
cgroup-make-the-mount-options-parsing-more-accurate.patch
cgroup-notify-ns_cgroup-deprecated.patch
namespaces-remove-pid_ns-and-net_ns-experimental-status.patch
namespaces-default-all-the-namespaces-to-yes-when-config_namespaces-is-selected.patch
^ permalink raw reply
* Re: [RFC] arch generic way to trigger unknown NMIs
From: Maciej W. Rozycki @ 2010-10-07 22:45 UTC (permalink / raw)
To: Don Zickus
Cc: Andi Kleen, mingo, fweisbec, robert.richter, gorcunov,
linux-kernel
In-Reply-To: <20101007140112.GN10663@redhat.com>
On Thu, 7 Oct 2010, Don Zickus wrote:
> No I prefer a single one too, but there didn't seem to be a
> send_IPI_self() command, so I took the short route and sent it to
> everyone. :-(
Odd, APIC hardware does explicitly support such a mode (there are three
shorthands like this actually: all-but-self, all and self), so why don't
just add a suitable wrapper?
Maciej
^ permalink raw reply
* Re: [RFC/PATCH v3] usb: usb3.0 ch9 definitions
From: Daniel Walker @ 2010-10-07 22:47 UTC (permalink / raw)
To: Brokhman Tatyana
Cc: linux-usb, linux-arm-msm, Greg Kroah-Hartman, Matthew Wilcox,
Sarah Sharp, linux-kernel
In-Reply-To: <1286476470-15265-1-git-send-email-tlinder@codeaurora.org>
On Thu, 2010-10-07 at 20:34 +0200, Brokhman Tatyana wrote:
> Adding SuperSpeed usb definitions as defined by ch9 of the USB3.0 spec.
> This patch is a preparation for adding SuperSpeed support to the gadget
> framework.
>
> Signed-off-by: Brokhman Tatyana <tlinder@codeaurora.org>
Shouldn't your name be reversed? First Last . Isn't Tatyana your first
name?
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH v6] iio: light: Adding driver for ISL29018 ALS
From: rklein-DDmLM1+adcrQT0dZR+AlfA @ 2010-10-07 22:48 UTC (permalink / raw)
To: greg-U8xfFu+wG4EAvxtiuMwx3w
Cc: jic23-KWPb1pKIrIJaa/9Udqfwiw, joe-6d6DIl74uiNBDgjK7y7TUQ,
achew-DDmLM1+adcrQT0dZR+AlfA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
ldewangan-DDmLM1+adcrQT0dZR+AlfA, Rhyland Klein
From: Rhyland Klein <rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
adding support for the ISL 29018 ambient light and proximity sensor.
Addressed comments from reviews by Jonathan Cameron and Joe Perches
* Removed some excess dbg prints that only printed function name
* Renamed some properties to make them more descriptive
* Added a property to list available adc resolutions
* Defined arrays for resolutions/ranges as static const
* Change loops initialization to memset for extensibility.
* used sizeof() instead of ARRAY_SIZE() to be safer
* Added a property to list available adc ranges
* Fixed warnings and property names.
Signed-off-by: Rhyland Klein <rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
---
.../staging/iio/Documentation/sysfs-bus-iio-light | 64 +++
drivers/staging/iio/light/Kconfig | 12 +
drivers/staging/iio/light/Makefile | 1 +
drivers/staging/iio/light/isl29018.c | 563 ++++++++++++++++++++
4 files changed, 640 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-light
create mode 100644 drivers/staging/iio/light/isl29018.c
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-light b/drivers/staging/iio/Documentation/sysfs-bus-iio-light
new file mode 100644
index 0000000..5d84856
--- /dev/null
+++ b/drivers/staging/iio/Documentation/sysfs-bus-iio-light
@@ -0,0 +1,64 @@
+
+What: /sys/bus/iio/devices/device[n]/range
+KernelVersion: 2.6.37
+Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+Description:
+ Hardware dependent ADC Full Scale Range used for some ambient
+ light sensors in calculating lux.
+
+What: /sys/bus/iio/devices/device[n]/range_available
+KernelVersion: 2.6.37
+Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+Description:
+ Hardware dependent supported vales for ADC Full Scale Range.
+
+What: /sys/bus/iio/devices/device[n]/adc_resolution
+KernelVersion: 2.6.37
+Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+Description:
+ Hardware dependent ADC resolution of the ambient light sensor
+ used in calculating the lux.
+
+What: /sys/bus/iio/devices/device[n]/adc_resolution_available
+KernelVersion: 2.6.37
+Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+Description:
+ Hardware dependent list of possible values supported for the
+ adc_resolution of the given sensor.
+
+What: /sys/bus/iio/devices/device[n]/illuminance0[_input|_raw]
+KernelVersion: 2.6.35
+Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+Description:
+ This should return the calculated lux from the light sensor. If
+ it comes back in SI units, it should also include _input else it
+ should include _raw to signify it is not in SI units.
+
+What: /sys/.../device[n]/proximity_on_chip_ambient_infrared_supression
+KernelVersion: 2.6.37
+Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+Description:
+ Hardware dependent mode for an ALS device to calculate the value
+ in proximity mode. When this is enabled, then the device should
+ use a infrared sensor reading to remove infrared noise from the
+ proximity reading. If this is not enabled, the driver can still
+ do this calculation manually by reading the infrared sensor
+ value and doing the negation in sw.
+
+What: /sys/bus/iio/devices/device[n]/proximity[_input|_raw]
+KernelVersion: 2.6.37
+Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+Description:
+ This property is supported by proximity sensors and should be
+ used to return the value of a reading by the sensor. If this
+ value is returned in SI units, it should also include _input
+ but if it is not, then it should include _raw.
+
+What: /sys/bus/iio/devices/device[n]/intensity_infrared[_input|_raw]
+KernelVersion: 2.6.37
+Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+Description:
+ This property is supported by sensors that have an infrared
+ sensing mode. This value should be the output from a reading
+ and if expressed in SI units, should include _input. If this
+ value is not in SI units, then it should include _raw.
diff --git a/drivers/staging/iio/light/Kconfig b/drivers/staging/iio/light/Kconfig
index 3ddc478..36d8bbe 100644
--- a/drivers/staging/iio/light/Kconfig
+++ b/drivers/staging/iio/light/Kconfig
@@ -12,3 +12,15 @@ config SENSORS_TSL2563
This driver can also be built as a module. If so, the module
will be called tsl2563.
+
+config SENSORS_ISL29018
+ tristate "ISL 29018 light and proximity sensor"
+ depends on I2C
+ default n
+ help
+ If you say yes here you get support for ambient light sensing and
+ proximity infrared sensing from Intersil ISL29018.
+ This driver will provide the measurements of ambient light intensity
+ in lux, proximity infrared sensing and normal infrared sensing.
+ Data from sensor is accessible via sysfs.
+
diff --git a/drivers/staging/iio/light/Makefile b/drivers/staging/iio/light/Makefile
index 30f3300..9142c0e 100644
--- a/drivers/staging/iio/light/Makefile
+++ b/drivers/staging/iio/light/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
+obj-$(CONFIG_SENSORS_ISL29018) += isl29018.o
diff --git a/drivers/staging/iio/light/isl29018.c b/drivers/staging/iio/light/isl29018.c
new file mode 100644
index 0000000..f919cc1
--- /dev/null
+++ b/drivers/staging/iio/light/isl29018.c
@@ -0,0 +1,563 @@
+/*
+ * A iio driver for the light sensor ISL 29018.
+ *
+ * IIO driver for monitoring ambient light intensity in luxi, proximity
+ * sensing and infrared sensing.
+ *
+ * Copyright (c) 2010, NVIDIA Corporation.
+ *
+ * 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.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include "../iio.h"
+
+#define CONVERSION_TIME_MS 100
+
+#define ISL29018_REG_ADD_COMMAND1 0x00
+#define COMMMAND1_OPMODE_SHIFT 5
+#define COMMMAND1_OPMODE_MASK (7 << COMMMAND1_OPMODE_SHIFT)
+#define COMMMAND1_OPMODE_POWER_DOWN 0
+#define COMMMAND1_OPMODE_ALS_ONCE 1
+#define COMMMAND1_OPMODE_IR_ONCE 2
+#define COMMMAND1_OPMODE_PROX_ONCE 3
+
+#define ISL29018_REG_ADD_COMMANDII 0x01
+#define COMMANDII_RESOLUTION_SHIFT 2
+#define COMMANDII_RESOLUTION_MASK (0x3 << COMMANDII_RESOLUTION_SHIFT)
+
+#define COMMANDII_RANGE_SHIFT 0
+#define COMMANDII_RANGE_MASK (0x3 << COMMANDII_RANGE_SHIFT)
+
+#define COMMANDII_SCHEME_SHIFT 7
+#define COMMANDII_SCHEME_MASK (0x1 << COMMANDII_SCHEME_SHIFT)
+
+#define ISL29018_REG_ADD_DATA_LSB 0x02
+#define ISL29018_REG_ADD_DATA_MSB 0x03
+#define ISL29018_MAX_REGS ISL29018_REG_ADD_DATA_MSB
+
+struct isl29018_chip {
+ struct iio_dev *indio_dev;
+ struct i2c_client *client;
+ struct mutex lock;
+ unsigned int range;
+ unsigned int adc_bit;
+ int prox_scheme;
+ u8 reg_cache[ISL29018_MAX_REGS];
+};
+
+static int isl29018_write_data(struct i2c_client *client, u8 reg,
+ u8 val, u8 mask, u8 shift)
+{
+ u8 regval;
+ int ret = 0;
+ struct isl29018_chip *chip = i2c_get_clientdata(client);
+
+ regval = chip->reg_cache[reg];
+ regval &= ~mask;
+ regval |= val << shift;
+
+ ret = i2c_smbus_write_byte_data(client, reg, regval);
+ if (ret) {
+ dev_err(&client->dev, "Write to device fails status %x\n", ret);
+ return ret;
+ }
+ chip->reg_cache[reg] = regval;
+
+ return 0;
+}
+
+static int isl29018_set_range(struct i2c_client *client, unsigned long range,
+ unsigned int *new_range)
+{
+ static const unsigned long supp_ranges[] = {1000, 4000, 16000, 64000};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(supp_ranges); ++i) {
+ if (range <= supp_ranges[i]) {
+ *new_range = (unsigned int)supp_ranges[i];
+ break;
+ }
+ }
+
+ if (i >= ARRAY_SIZE(supp_ranges))
+ return -EINVAL;
+
+ return isl29018_write_data(client, ISL29018_REG_ADD_COMMANDII,
+ i, COMMANDII_RANGE_MASK, COMMANDII_RANGE_SHIFT);
+}
+
+static int isl29018_set_resolution(struct i2c_client *client,
+ unsigned long adcbit, unsigned int *conf_adc_bit)
+{
+ static const unsigned long supp_adcbit[] = {16, 12, 8, 4};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(supp_adcbit); ++i) {
+ if (adcbit >= supp_adcbit[i]) {
+ *conf_adc_bit = (unsigned int)supp_adcbit[i];
+ break;
+ }
+ }
+
+ if (i >= ARRAY_SIZE(supp_adcbit))
+ return -EINVAL;
+
+ return isl29018_write_data(client, ISL29018_REG_ADD_COMMANDII,
+ i, COMMANDII_RESOLUTION_MASK,
+ COMMANDII_RESOLUTION_SHIFT);
+}
+
+static int isl29018_read_sensor_input(struct i2c_client *client, int mode)
+{
+ int status;
+ int lsb;
+ int msb;
+
+ /* Set mode */
+ status = isl29018_write_data(client, ISL29018_REG_ADD_COMMAND1,
+ mode, COMMMAND1_OPMODE_MASK, COMMMAND1_OPMODE_SHIFT);
+ if (status) {
+ dev_err(&client->dev, "Error in setting operating mode\n");
+ return status;
+ }
+ msleep(CONVERSION_TIME_MS);
+ lsb = i2c_smbus_read_byte_data(client, ISL29018_REG_ADD_DATA_LSB);
+ if (lsb < 0) {
+ dev_err(&client->dev, "Error in reading LSB DATA\n");
+ return lsb;
+ }
+
+ msb = i2c_smbus_read_byte_data(client, ISL29018_REG_ADD_DATA_MSB);
+ if (msb < 0) {
+ dev_err(&client->dev, "Error in reading MSB DATA\n");
+ return msb;
+ }
+ dev_vdbg(&client->dev, "MSB 0x%x and LSB 0x%x\n", msb, lsb);
+
+ return (msb << 8) | lsb;
+}
+
+static int isl29018_read_lux(struct i2c_client *client, int *lux)
+{
+ int lux_data;
+ struct isl29018_chip *chip = i2c_get_clientdata(client);
+
+ lux_data = isl29018_read_sensor_input(client,
+ COMMMAND1_OPMODE_ALS_ONCE);
+
+ if (lux_data < 0)
+ return lux_data;
+
+ *lux = (lux_data * chip->range) >> chip->adc_bit;
+
+ return 0;
+}
+
+static int isl29018_read_ir(struct i2c_client *client, int *ir)
+{
+ int ir_data;
+
+ ir_data = isl29018_read_sensor_input(client, COMMMAND1_OPMODE_IR_ONCE);
+
+ if (ir_data < 0)
+ return ir_data;
+
+ *ir = ir_data;
+
+ return 0;
+}
+
+static int isl29018_read_proximity_ir(struct i2c_client *client, int scheme,
+ int *near_ir)
+{
+ int status;
+ int prox_data = -1;
+ int ir_data = -1;
+
+ /* Do proximity sensing with required scheme */
+ status = isl29018_write_data(client, ISL29018_REG_ADD_COMMANDII,
+ scheme, COMMANDII_SCHEME_MASK, COMMANDII_SCHEME_SHIFT);
+ if (status) {
+ dev_err(&client->dev, "Error in setting operating mode\n");
+ return status;
+ }
+
+ prox_data = isl29018_read_sensor_input(client,
+ COMMMAND1_OPMODE_PROX_ONCE);
+ if (prox_data < 0)
+ return prox_data;
+
+ if (scheme == 1) {
+ *near_ir = prox_data;
+ return 0;
+ }
+
+ ir_data = isl29018_read_sensor_input(client,
+ COMMMAND1_OPMODE_IR_ONCE);
+
+ if (ir_data < 0)
+ return ir_data;
+
+ if (prox_data >= ir_data)
+ *near_ir = prox_data - ir_data;
+ else
+ *near_ir = 0;
+
+ return 0;
+}
+
+static ssize_t get_sensor_data(struct device *dev, char *buf, int mode)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+ struct i2c_client *client = chip->client;
+ int value = 0;
+ int status;
+
+ mutex_lock(&chip->lock);
+ switch (mode) {
+ case COMMMAND1_OPMODE_PROX_ONCE:
+ status = isl29018_read_proximity_ir(client,
+ chip->prox_scheme, &value);
+ break;
+
+ case COMMMAND1_OPMODE_ALS_ONCE:
+ status = isl29018_read_lux(client, &value);
+ break;
+
+ case COMMMAND1_OPMODE_IR_ONCE:
+ status = isl29018_read_ir(client, &value);
+ break;
+
+ default:
+ dev_err(&client->dev, "Mode %d is not supported\n", mode);
+ mutex_unlock(&chip->lock);
+ return -EBUSY;
+ }
+ if (status < 0) {
+ dev_err(&client->dev, "Error in Reading data");
+ mutex_unlock(&chip->lock);
+ return status;
+ }
+
+ mutex_unlock(&chip->lock);
+
+ return sprintf(buf, "%d\n", value);
+}
+
+/* Sysfs interface */
+/* range */
+static ssize_t show_range(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+
+ return sprintf(buf, "%u\n", chip->range);
+}
+
+static ssize_t store_range(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+ struct i2c_client *client = chip->client;
+ int status;
+ unsigned long lval;
+ unsigned int new_range;
+
+ if (strict_strtoul(buf, 10, &lval))
+ return -EINVAL;
+
+ if (!(lval == 1000UL || lval == 4000UL ||
+ lval == 16000UL || lval == 64000UL)) {
+ dev_err(dev, "The range is not supported\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&chip->lock);
+ status = isl29018_set_range(client, lval, &new_range);
+ if (status < 0) {
+ mutex_unlock(&chip->lock);
+ dev_err(dev, "Error in setting max range\n");
+ return status;
+ }
+ chip->range = new_range;
+ mutex_unlock(&chip->lock);
+
+ return count;
+}
+
+/* resolution */
+static ssize_t show_resolution(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+
+ return sprintf(buf, "%u\n", chip->adc_bit);
+}
+
+static ssize_t store_resolution(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+ struct i2c_client *client = chip->client;
+ int status;
+ unsigned long lval;
+ unsigned int new_adc_bit;
+
+ if (strict_strtoul(buf, 10, &lval))
+ return -EINVAL;
+ if (!(lval == 4 || lval == 8 || lval == 12 || lval == 16)) {
+ dev_err(dev, "The resolution is not supported\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&chip->lock);
+ status = isl29018_set_resolution(client, lval, &new_adc_bit);
+ if (status < 0) {
+ mutex_unlock(&chip->lock);
+ dev_err(dev, "Error in setting resolution\n");
+ return status;
+ }
+ chip->adc_bit = new_adc_bit;
+ mutex_unlock(&chip->lock);
+
+ return count;
+}
+
+/* proximity scheme */
+static ssize_t show_prox_infrared_supression(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+
+ /* return the "proximity scheme" i.e. if the chip does on chip
+ infrared supression (1 means perform on chip supression) */
+ return sprintf(buf, "%d\n", chip->prox_scheme);
+}
+
+static ssize_t store_prox_infrared_supression(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+ unsigned long lval;
+
+ if (strict_strtoul(buf, 10, &lval))
+ return -EINVAL;
+ if (!(lval == 0UL || lval == 1UL)) {
+ dev_err(dev, "The mode is not supported\n");
+ return -EINVAL;
+ }
+
+ /* get the "proximity scheme" i.e. if the chip does on chip
+ infrared supression (1 means perform on chip supression) */
+ mutex_lock(&chip->lock);
+ chip->prox_scheme = (int)lval;
+ mutex_unlock(&chip->lock);
+
+ return count;
+}
+
+/* Read lux */
+static ssize_t show_lux(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ return get_sensor_data(dev, buf, COMMMAND1_OPMODE_ALS_ONCE);
+}
+
+/* Read ir */
+static ssize_t show_ir(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ return get_sensor_data(dev, buf, COMMMAND1_OPMODE_IR_ONCE);
+}
+
+/* Read nearest ir */
+static ssize_t show_proxim_ir(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ return get_sensor_data(dev, buf, COMMMAND1_OPMODE_PROX_ONCE);
+}
+
+/* Read name */
+static ssize_t show_name(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+
+ return sprintf(buf, "%s\n", chip->client->name);
+}
+
+static IIO_DEVICE_ATTR(range, S_IRUGO | S_IWUSR, show_range, store_range, 0);
+static IIO_CONST_ATTR(range_available, "1000 4000 16000 64000");
+static IIO_CONST_ATTR(adc_resolution_available, "4 8 12 16");
+static IIO_DEVICE_ATTR(adc_resolution, S_IRUGO | S_IWUSR,
+ show_resolution, store_resolution, 0);
+static IIO_DEVICE_ATTR(proximity_on_chip_ambient_infrared_supression,
+ S_IRUGO | S_IWUSR,
+ show_prox_infrared_supression,
+ store_prox_infrared_supression, 0);
+static IIO_DEVICE_ATTR(illuminance0_input, S_IRUGO, show_lux, NULL, 0);
+static IIO_DEVICE_ATTR(intensity_infrared_raw, S_IRUGO, show_ir, NULL, 0);
+static IIO_DEVICE_ATTR(proximity_raw, S_IRUGO, show_proxim_ir, NULL, 0);
+static IIO_DEVICE_ATTR(name, S_IRUGO, show_name, NULL, 0);
+
+#define ISL29018_DEV_ATTR(name) (&iio_dev_attr_##name.dev_attr.attr)
+#define ISL29018_CONST_ATTR(name) (&iio_const_attr_##name.dev_attr.attr)
+static struct attribute *isl29018_attributes[] = {
+ ISL29018_DEV_ATTR(name),
+ ISL29018_DEV_ATTR(range),
+ ISL29018_CONST_ATTR(range_available),
+ ISL29018_DEV_ATTR(adc_resolution),
+ ISL29018_CONST_ATTR(adc_resolution_available),
+ ISL29018_DEV_ATTR(proximity_on_chip_ambient_infrared_supression),
+ ISL29018_DEV_ATTR(illuminance0_input),
+ ISL29018_DEV_ATTR(intensity_infrared_raw),
+ ISL29018_DEV_ATTR(proximity_raw),
+ NULL
+};
+
+static const struct attribute_group isl29108_group = {
+ .attrs = isl29018_attributes,
+};
+
+static int isl29018_chip_init(struct i2c_client *client)
+{
+ struct isl29018_chip *chip = i2c_get_clientdata(client);
+ int status;
+ int new_adc_bit;
+ unsigned int new_range;
+
+ memset(chip->reg_cache, 0, sizeof(chip->reg_cache));
+
+ /* set defaults */
+ status = isl29018_set_range(client, chip->range, &new_range);
+ if (status < 0) {
+ dev_err(&client->dev, "Init of isl29018 fails\n");
+ return status;
+ }
+
+ status = isl29018_set_resolution(client, chip->adc_bit,
+ &new_adc_bit);
+
+ return 0;
+}
+
+static int __devinit isl29018_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct isl29018_chip *chip;
+ int err;
+
+ chip = kzalloc(sizeof(struct isl29018_chip), GFP_KERNEL);
+ if (!chip) {
+ dev_err(&client->dev, "Memory allocation fails\n");
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ i2c_set_clientdata(client, chip);
+ chip->client = client;
+
+ mutex_init(&chip->lock);
+
+ chip->range = 1000;
+ chip->adc_bit = 16;
+
+ err = isl29018_chip_init(client);
+ if (err)
+ goto exit_free;
+
+ chip->indio_dev = iio_allocate_device();
+ if (!chip->indio_dev) {
+ dev_err(&client->dev, "iio allocation fails\n");
+ goto exit_free;
+ }
+ chip->indio_dev->attrs = &isl29108_group;
+ chip->indio_dev->dev.parent = &client->dev;
+ chip->indio_dev->dev_data = (void *)(chip);
+ chip->indio_dev->driver_module = THIS_MODULE;
+ chip->indio_dev->modes = INDIO_DIRECT_MODE;
+ err = iio_device_register(chip->indio_dev);
+ if (err) {
+ dev_err(&client->dev, "iio registration fails\n");
+ goto exit_iio_free;
+ }
+
+ return 0;
+exit_iio_free:
+ iio_free_device(chip->indio_dev);
+exit_free:
+ kfree(chip);
+exit:
+ return err;
+}
+
+static int __devexit isl29018_remove(struct i2c_client *client)
+{
+ struct isl29018_chip *chip = i2c_get_clientdata(client);
+
+ dev_dbg(&client->dev, "%s()\n", __func__);
+ iio_device_unregister(chip->indio_dev);
+ kfree(chip);
+
+ return 0;
+}
+
+static const struct i2c_device_id isl29018_id[] = {
+ {"isl29018", 0},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, isl29018_id);
+
+static struct i2c_driver isl29018_driver = {
+ .class = I2C_CLASS_HWMON,
+ .driver = {
+ .name = "isl29018",
+ .owner = THIS_MODULE,
+ },
+ .probe = isl29018_probe,
+ .remove = __devexit_p(isl29018_remove),
+ .id_table = isl29018_id,
+};
+
+static int __init isl29018_init(void)
+{
+ return i2c_add_driver(&isl29018_driver);
+}
+
+static void __exit isl29018_exit(void)
+{
+ i2c_del_driver(&isl29018_driver);
+}
+
+module_init(isl29018_init);
+module_exit(isl29018_exit);
+
+MODULE_DESCRIPTION("ISL29018 Ambient Light Sensor driver");
+MODULE_LICENSE("GPL");
--
1.7.0.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Sage Weil @ 2010-10-07 22:45 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, kvm, Yehuda Sadeh Weinraub, qemu-devel, ceph-devel,
Christian Brunner
In-Reply-To: <4CAE41BD.2070508@codemonkey.ws>
On Thu, 7 Oct 2010, Anthony Liguori wrote:
> On 10/07/2010 04:49 PM, Yehuda Sadeh Weinraub wrote:
> > On Thu, Oct 7, 2010 at 2:04 PM, Anthony Liguori<anthony@codemonkey.ws>
> > wrote:
> >
> > > On 10/07/2010 03:47 PM, Yehuda Sadeh Weinraub wrote:
> > >
> > > > > How is that possible? Are the callbacks delivered in the context of a
> > > > > different thread? If so, don't you need locking?
> > > > >
> > > > >
> > > > Not sure I'm completely following you. The callbacks are delivered in
> > > > the context of a different thread, but won't run concurrently.
> > > >
> > > Concurrently to what? How do you prevent them from running concurrently
> > > with qemu?
> > >
> > There are two types of callbacks. The first is for rados aio
> > completions, and the second one is the one added later for the fd glue
> > layer.
> >
>
> This is a bad architecture for something like qemu. You could create a
> pipe and use the pipe to signal to qemu. Same principle as eventfd.
> Ideally, you would do this in the library itself.
I'm sorry, I'm having a hard time understanding what it is you're
objecting to, or what you would prefer, as there are two different things
we're talking about here (callbacks and fd glue/pipes). (Please bear with
me as I am not a qemu expert!)
The first is the aio completion. You said a few messages back:
> It looks like you just use the eventfd to signal aio completion
> callbacks. A better way to do this would be to schedule a bottom half.
This is what we're doing. The librados makes a callback to rbd.c's
rbd_finish_aiocb(), which updates some internal rbd accounting and then
calls qemu_bh_schedule(). Is that part right?
The second part is an fd (currently created via eventfd(), but I don't
think it matters where it comes from) that was later added because
qemu_aio_flush() wouldn't trigger when our aio's completed (and scheduled
the bottom halves). This was proposed by Simone Gotti, who had problems
with live migration:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg35516.html
Apparently calling the bottom half isn't sufficient to wake up a blocked
qemu_aio_flush()? His solution was to create an eventfd() fd, write a
word to it in the aio completion callback (before we schedule the bh), and
add the necessary callbacks to make qemu_aio_flush() behave.
Is the problem simply that we should be using pipe(2) instead of
eventfd(2)?
So far I've heard that we should be scheduling the bottom halves (we are),
and we should be using a pipe to signal qemu (we're using an fd created by
eventfd(2)).
Thanks,
sage
>
> Regards,
>
> Anthony Liguori
>
> > The first callback, called by librados whenever aio completes, runs in
> > the context of a single librados thread:
> >
> > +static void rbd_finish_aiocb(rados_completion_t c, RADOSCB *rcb)
> > +{
> > + RBDAIOCB *acb = rcb->acb;
> > rcb is per a single aio. Was created before and will be destroyed
> > here, whereas acb is shared between a few aios, however, it was
> > generated before the first aio was created.
> >
> > + int64_t r;
> > + uint64_t buf = 1;
> > + int i;
> > +
> > + acb->aiocnt--;
> >
> > acb->aiocnt has been set before initiating all the aios, so it's ok to
> > touch it now. Same goes to all acb fields.
> >
> > + r = rados_aio_get_return_value(c);
> > + rados_aio_release(c);
> > + if (acb->write) {
> > + if (r< 0) {
> > + acb->ret = r;
> > + acb->error = 1;
> > + } else if (!acb->error) {
> > + acb->ret += rcb->segsize;
> > + }
> > + } else {
> > + if (r == -ENOENT) {
> > + memset(rcb->buf, 0, rcb->segsize);
> > + if (!acb->error) {
> > + acb->ret += rcb->segsize;
> > + }
> > + } else if (r< 0) {
> > + acb->ret = r;
> > + acb->error = 1;
> > + } else if (r< rcb->segsize) {
> > + memset(rcb->buf + r, 0, rcb->segsize - r);
> > + if (!acb->error) {
> > + acb->ret += rcb->segsize;
> > + }
> > + } else if (!acb->error) {
> > + acb->ret += r;
> > + }
> > + }
> > + if (write(acb->s->efd,&buf, sizeof(buf))< 0)
> > This will wake up the io_read()
> >
> > + error_report("failed writing to acb->s->efd\n");
> > + qemu_free(rcb);
> > + i = 0;
> > + if (!acb->aiocnt&& acb->bh) {
> > + qemu_bh_schedule(acb->bh);
> > This is the only qemu related call in here, seems safe to call it.
> >
> > + }
> > +}
> >
> > The scheduled bh function will be called only after all aios that
> > relate to this specific aio set are done, so the following seems ok,
> > as there's no more acb references.
> > +static void rbd_aio_bh_cb(void *opaque)
> > +{
> > + RBDAIOCB *acb = opaque;
> > + uint64_t buf = 1;
> > +
> > + if (!acb->write) {
> > + qemu_iovec_from_buffer(acb->qiov, acb->bounce, acb->qiov->size);
> > + }
> > + qemu_vfree(acb->bounce);
> > + acb->common.cb(acb->common.opaque, (acb->ret> 0 ? 0 : acb->ret));
> > + qemu_bh_delete(acb->bh);
> > + acb->bh = NULL;
> > +
> > + if (write(acb->s->efd,&buf, sizeof(buf))< 0)
> > + error_report("failed writing to acb->s->efd\n");
> > + qemu_aio_release(acb);
> > +}
> >
> > Now, the second ones are the io_read(), in which we have our glue fd.
> > We send uint64 per each completed io
> >
> > +static void rbd_aio_completion_cb(void *opaque)
> > +{
> > + BDRVRBDState *s = opaque;
> > +
> > + uint64_t val;
> > + ssize_t ret;
> > +
> > + do {
> > + if ((ret = read(s->efd,&val, sizeof(val)))> 0) {
> > + s->qemu_aio_count -= val;
> > There is an issue here with s->qemu_aio_count which needs to be
> > protected by a mutex. Other than that, it just reads from s->efd.
> >
> > + }
> > + } while (ret< 0&& errno == EINTR);
> > +
> > + return;
> > +}
> > +
> > +static int rbd_aio_flush_cb(void *opaque)
> > +{
> > + BDRVRBDState *s = opaque;
> > +
> > + return (s->qemu_aio_count> 0);
> > Same here as with the previous one, needs a mutex around s->qemu_aio_count.
> >
> > +}
> >
> >
> > > If you saw lock ups, I bet that's what it was from.
> > >
> > >
> > As I explained before, before introducing the fd glue layer, the lack
> > of fd associated with our block device caused that there was no way
> > for qemu to check whether all aios were flushed or not, which didn't
> > work well when doing migration/savevm.
> >
> > Thanks,
> > Yehuda
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH v6] iio: light: Adding driver for ISL29018 ALS
From: rklein @ 2010-10-07 22:48 UTC (permalink / raw)
To: greg
Cc: jic23, joe, achew, olof, linux-i2c, linux-kernel, linux-iio,
ldewangan, Rhyland Klein
From: Rhyland Klein <rklein@nvidia.com>
adding support for the ISL 29018 ambient light and proximity sensor.
Addressed comments from reviews by Jonathan Cameron and Joe Perches
* Removed some excess dbg prints that only printed function name
* Renamed some properties to make them more descriptive
* Added a property to list available adc resolutions
* Defined arrays for resolutions/ranges as static const
* Change loops initialization to memset for extensibility.
* used sizeof() instead of ARRAY_SIZE() to be safer
* Added a property to list available adc ranges
* Fixed warnings and property names.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
---
.../staging/iio/Documentation/sysfs-bus-iio-light | 64 +++
drivers/staging/iio/light/Kconfig | 12 +
drivers/staging/iio/light/Makefile | 1 +
drivers/staging/iio/light/isl29018.c | 563 ++++++++++++++++++++
4 files changed, 640 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-light
create mode 100644 drivers/staging/iio/light/isl29018.c
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio-light b/drivers/staging/iio/Documentation/sysfs-bus-iio-light
new file mode 100644
index 0000000..5d84856
--- /dev/null
+++ b/drivers/staging/iio/Documentation/sysfs-bus-iio-light
@@ -0,0 +1,64 @@
+
+What: /sys/bus/iio/devices/device[n]/range
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Hardware dependent ADC Full Scale Range used for some ambient
+ light sensors in calculating lux.
+
+What: /sys/bus/iio/devices/device[n]/range_available
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Hardware dependent supported vales for ADC Full Scale Range.
+
+What: /sys/bus/iio/devices/device[n]/adc_resolution
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Hardware dependent ADC resolution of the ambient light sensor
+ used in calculating the lux.
+
+What: /sys/bus/iio/devices/device[n]/adc_resolution_available
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Hardware dependent list of possible values supported for the
+ adc_resolution of the given sensor.
+
+What: /sys/bus/iio/devices/device[n]/illuminance0[_input|_raw]
+KernelVersion: 2.6.35
+Contact: linux-iio@vger.kernel.org
+Description:
+ This should return the calculated lux from the light sensor. If
+ it comes back in SI units, it should also include _input else it
+ should include _raw to signify it is not in SI units.
+
+What: /sys/.../device[n]/proximity_on_chip_ambient_infrared_supression
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ Hardware dependent mode for an ALS device to calculate the value
+ in proximity mode. When this is enabled, then the device should
+ use a infrared sensor reading to remove infrared noise from the
+ proximity reading. If this is not enabled, the driver can still
+ do this calculation manually by reading the infrared sensor
+ value and doing the negation in sw.
+
+What: /sys/bus/iio/devices/device[n]/proximity[_input|_raw]
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ This property is supported by proximity sensors and should be
+ used to return the value of a reading by the sensor. If this
+ value is returned in SI units, it should also include _input
+ but if it is not, then it should include _raw.
+
+What: /sys/bus/iio/devices/device[n]/intensity_infrared[_input|_raw]
+KernelVersion: 2.6.37
+Contact: linux-iio@vger.kernel.org
+Description:
+ This property is supported by sensors that have an infrared
+ sensing mode. This value should be the output from a reading
+ and if expressed in SI units, should include _input. If this
+ value is not in SI units, then it should include _raw.
diff --git a/drivers/staging/iio/light/Kconfig b/drivers/staging/iio/light/Kconfig
index 3ddc478..36d8bbe 100644
--- a/drivers/staging/iio/light/Kconfig
+++ b/drivers/staging/iio/light/Kconfig
@@ -12,3 +12,15 @@ config SENSORS_TSL2563
This driver can also be built as a module. If so, the module
will be called tsl2563.
+
+config SENSORS_ISL29018
+ tristate "ISL 29018 light and proximity sensor"
+ depends on I2C
+ default n
+ help
+ If you say yes here you get support for ambient light sensing and
+ proximity infrared sensing from Intersil ISL29018.
+ This driver will provide the measurements of ambient light intensity
+ in lux, proximity infrared sensing and normal infrared sensing.
+ Data from sensor is accessible via sysfs.
+
diff --git a/drivers/staging/iio/light/Makefile b/drivers/staging/iio/light/Makefile
index 30f3300..9142c0e 100644
--- a/drivers/staging/iio/light/Makefile
+++ b/drivers/staging/iio/light/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
+obj-$(CONFIG_SENSORS_ISL29018) += isl29018.o
diff --git a/drivers/staging/iio/light/isl29018.c b/drivers/staging/iio/light/isl29018.c
new file mode 100644
index 0000000..f919cc1
--- /dev/null
+++ b/drivers/staging/iio/light/isl29018.c
@@ -0,0 +1,563 @@
+/*
+ * A iio driver for the light sensor ISL 29018.
+ *
+ * IIO driver for monitoring ambient light intensity in luxi, proximity
+ * sensing and infrared sensing.
+ *
+ * Copyright (c) 2010, NVIDIA Corporation.
+ *
+ * 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.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include "../iio.h"
+
+#define CONVERSION_TIME_MS 100
+
+#define ISL29018_REG_ADD_COMMAND1 0x00
+#define COMMMAND1_OPMODE_SHIFT 5
+#define COMMMAND1_OPMODE_MASK (7 << COMMMAND1_OPMODE_SHIFT)
+#define COMMMAND1_OPMODE_POWER_DOWN 0
+#define COMMMAND1_OPMODE_ALS_ONCE 1
+#define COMMMAND1_OPMODE_IR_ONCE 2
+#define COMMMAND1_OPMODE_PROX_ONCE 3
+
+#define ISL29018_REG_ADD_COMMANDII 0x01
+#define COMMANDII_RESOLUTION_SHIFT 2
+#define COMMANDII_RESOLUTION_MASK (0x3 << COMMANDII_RESOLUTION_SHIFT)
+
+#define COMMANDII_RANGE_SHIFT 0
+#define COMMANDII_RANGE_MASK (0x3 << COMMANDII_RANGE_SHIFT)
+
+#define COMMANDII_SCHEME_SHIFT 7
+#define COMMANDII_SCHEME_MASK (0x1 << COMMANDII_SCHEME_SHIFT)
+
+#define ISL29018_REG_ADD_DATA_LSB 0x02
+#define ISL29018_REG_ADD_DATA_MSB 0x03
+#define ISL29018_MAX_REGS ISL29018_REG_ADD_DATA_MSB
+
+struct isl29018_chip {
+ struct iio_dev *indio_dev;
+ struct i2c_client *client;
+ struct mutex lock;
+ unsigned int range;
+ unsigned int adc_bit;
+ int prox_scheme;
+ u8 reg_cache[ISL29018_MAX_REGS];
+};
+
+static int isl29018_write_data(struct i2c_client *client, u8 reg,
+ u8 val, u8 mask, u8 shift)
+{
+ u8 regval;
+ int ret = 0;
+ struct isl29018_chip *chip = i2c_get_clientdata(client);
+
+ regval = chip->reg_cache[reg];
+ regval &= ~mask;
+ regval |= val << shift;
+
+ ret = i2c_smbus_write_byte_data(client, reg, regval);
+ if (ret) {
+ dev_err(&client->dev, "Write to device fails status %x\n", ret);
+ return ret;
+ }
+ chip->reg_cache[reg] = regval;
+
+ return 0;
+}
+
+static int isl29018_set_range(struct i2c_client *client, unsigned long range,
+ unsigned int *new_range)
+{
+ static const unsigned long supp_ranges[] = {1000, 4000, 16000, 64000};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(supp_ranges); ++i) {
+ if (range <= supp_ranges[i]) {
+ *new_range = (unsigned int)supp_ranges[i];
+ break;
+ }
+ }
+
+ if (i >= ARRAY_SIZE(supp_ranges))
+ return -EINVAL;
+
+ return isl29018_write_data(client, ISL29018_REG_ADD_COMMANDII,
+ i, COMMANDII_RANGE_MASK, COMMANDII_RANGE_SHIFT);
+}
+
+static int isl29018_set_resolution(struct i2c_client *client,
+ unsigned long adcbit, unsigned int *conf_adc_bit)
+{
+ static const unsigned long supp_adcbit[] = {16, 12, 8, 4};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(supp_adcbit); ++i) {
+ if (adcbit >= supp_adcbit[i]) {
+ *conf_adc_bit = (unsigned int)supp_adcbit[i];
+ break;
+ }
+ }
+
+ if (i >= ARRAY_SIZE(supp_adcbit))
+ return -EINVAL;
+
+ return isl29018_write_data(client, ISL29018_REG_ADD_COMMANDII,
+ i, COMMANDII_RESOLUTION_MASK,
+ COMMANDII_RESOLUTION_SHIFT);
+}
+
+static int isl29018_read_sensor_input(struct i2c_client *client, int mode)
+{
+ int status;
+ int lsb;
+ int msb;
+
+ /* Set mode */
+ status = isl29018_write_data(client, ISL29018_REG_ADD_COMMAND1,
+ mode, COMMMAND1_OPMODE_MASK, COMMMAND1_OPMODE_SHIFT);
+ if (status) {
+ dev_err(&client->dev, "Error in setting operating mode\n");
+ return status;
+ }
+ msleep(CONVERSION_TIME_MS);
+ lsb = i2c_smbus_read_byte_data(client, ISL29018_REG_ADD_DATA_LSB);
+ if (lsb < 0) {
+ dev_err(&client->dev, "Error in reading LSB DATA\n");
+ return lsb;
+ }
+
+ msb = i2c_smbus_read_byte_data(client, ISL29018_REG_ADD_DATA_MSB);
+ if (msb < 0) {
+ dev_err(&client->dev, "Error in reading MSB DATA\n");
+ return msb;
+ }
+ dev_vdbg(&client->dev, "MSB 0x%x and LSB 0x%x\n", msb, lsb);
+
+ return (msb << 8) | lsb;
+}
+
+static int isl29018_read_lux(struct i2c_client *client, int *lux)
+{
+ int lux_data;
+ struct isl29018_chip *chip = i2c_get_clientdata(client);
+
+ lux_data = isl29018_read_sensor_input(client,
+ COMMMAND1_OPMODE_ALS_ONCE);
+
+ if (lux_data < 0)
+ return lux_data;
+
+ *lux = (lux_data * chip->range) >> chip->adc_bit;
+
+ return 0;
+}
+
+static int isl29018_read_ir(struct i2c_client *client, int *ir)
+{
+ int ir_data;
+
+ ir_data = isl29018_read_sensor_input(client, COMMMAND1_OPMODE_IR_ONCE);
+
+ if (ir_data < 0)
+ return ir_data;
+
+ *ir = ir_data;
+
+ return 0;
+}
+
+static int isl29018_read_proximity_ir(struct i2c_client *client, int scheme,
+ int *near_ir)
+{
+ int status;
+ int prox_data = -1;
+ int ir_data = -1;
+
+ /* Do proximity sensing with required scheme */
+ status = isl29018_write_data(client, ISL29018_REG_ADD_COMMANDII,
+ scheme, COMMANDII_SCHEME_MASK, COMMANDII_SCHEME_SHIFT);
+ if (status) {
+ dev_err(&client->dev, "Error in setting operating mode\n");
+ return status;
+ }
+
+ prox_data = isl29018_read_sensor_input(client,
+ COMMMAND1_OPMODE_PROX_ONCE);
+ if (prox_data < 0)
+ return prox_data;
+
+ if (scheme == 1) {
+ *near_ir = prox_data;
+ return 0;
+ }
+
+ ir_data = isl29018_read_sensor_input(client,
+ COMMMAND1_OPMODE_IR_ONCE);
+
+ if (ir_data < 0)
+ return ir_data;
+
+ if (prox_data >= ir_data)
+ *near_ir = prox_data - ir_data;
+ else
+ *near_ir = 0;
+
+ return 0;
+}
+
+static ssize_t get_sensor_data(struct device *dev, char *buf, int mode)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+ struct i2c_client *client = chip->client;
+ int value = 0;
+ int status;
+
+ mutex_lock(&chip->lock);
+ switch (mode) {
+ case COMMMAND1_OPMODE_PROX_ONCE:
+ status = isl29018_read_proximity_ir(client,
+ chip->prox_scheme, &value);
+ break;
+
+ case COMMMAND1_OPMODE_ALS_ONCE:
+ status = isl29018_read_lux(client, &value);
+ break;
+
+ case COMMMAND1_OPMODE_IR_ONCE:
+ status = isl29018_read_ir(client, &value);
+ break;
+
+ default:
+ dev_err(&client->dev, "Mode %d is not supported\n", mode);
+ mutex_unlock(&chip->lock);
+ return -EBUSY;
+ }
+ if (status < 0) {
+ dev_err(&client->dev, "Error in Reading data");
+ mutex_unlock(&chip->lock);
+ return status;
+ }
+
+ mutex_unlock(&chip->lock);
+
+ return sprintf(buf, "%d\n", value);
+}
+
+/* Sysfs interface */
+/* range */
+static ssize_t show_range(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+
+ return sprintf(buf, "%u\n", chip->range);
+}
+
+static ssize_t store_range(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+ struct i2c_client *client = chip->client;
+ int status;
+ unsigned long lval;
+ unsigned int new_range;
+
+ if (strict_strtoul(buf, 10, &lval))
+ return -EINVAL;
+
+ if (!(lval == 1000UL || lval == 4000UL ||
+ lval == 16000UL || lval == 64000UL)) {
+ dev_err(dev, "The range is not supported\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&chip->lock);
+ status = isl29018_set_range(client, lval, &new_range);
+ if (status < 0) {
+ mutex_unlock(&chip->lock);
+ dev_err(dev, "Error in setting max range\n");
+ return status;
+ }
+ chip->range = new_range;
+ mutex_unlock(&chip->lock);
+
+ return count;
+}
+
+/* resolution */
+static ssize_t show_resolution(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+
+ return sprintf(buf, "%u\n", chip->adc_bit);
+}
+
+static ssize_t store_resolution(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+ struct i2c_client *client = chip->client;
+ int status;
+ unsigned long lval;
+ unsigned int new_adc_bit;
+
+ if (strict_strtoul(buf, 10, &lval))
+ return -EINVAL;
+ if (!(lval == 4 || lval == 8 || lval == 12 || lval == 16)) {
+ dev_err(dev, "The resolution is not supported\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&chip->lock);
+ status = isl29018_set_resolution(client, lval, &new_adc_bit);
+ if (status < 0) {
+ mutex_unlock(&chip->lock);
+ dev_err(dev, "Error in setting resolution\n");
+ return status;
+ }
+ chip->adc_bit = new_adc_bit;
+ mutex_unlock(&chip->lock);
+
+ return count;
+}
+
+/* proximity scheme */
+static ssize_t show_prox_infrared_supression(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+
+ /* return the "proximity scheme" i.e. if the chip does on chip
+ infrared supression (1 means perform on chip supression) */
+ return sprintf(buf, "%d\n", chip->prox_scheme);
+}
+
+static ssize_t store_prox_infrared_supression(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+ unsigned long lval;
+
+ if (strict_strtoul(buf, 10, &lval))
+ return -EINVAL;
+ if (!(lval == 0UL || lval == 1UL)) {
+ dev_err(dev, "The mode is not supported\n");
+ return -EINVAL;
+ }
+
+ /* get the "proximity scheme" i.e. if the chip does on chip
+ infrared supression (1 means perform on chip supression) */
+ mutex_lock(&chip->lock);
+ chip->prox_scheme = (int)lval;
+ mutex_unlock(&chip->lock);
+
+ return count;
+}
+
+/* Read lux */
+static ssize_t show_lux(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ return get_sensor_data(dev, buf, COMMMAND1_OPMODE_ALS_ONCE);
+}
+
+/* Read ir */
+static ssize_t show_ir(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ return get_sensor_data(dev, buf, COMMMAND1_OPMODE_IR_ONCE);
+}
+
+/* Read nearest ir */
+static ssize_t show_proxim_ir(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ return get_sensor_data(dev, buf, COMMMAND1_OPMODE_PROX_ONCE);
+}
+
+/* Read name */
+static ssize_t show_name(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct isl29018_chip *chip = indio_dev->dev_data;
+
+ return sprintf(buf, "%s\n", chip->client->name);
+}
+
+static IIO_DEVICE_ATTR(range, S_IRUGO | S_IWUSR, show_range, store_range, 0);
+static IIO_CONST_ATTR(range_available, "1000 4000 16000 64000");
+static IIO_CONST_ATTR(adc_resolution_available, "4 8 12 16");
+static IIO_DEVICE_ATTR(adc_resolution, S_IRUGO | S_IWUSR,
+ show_resolution, store_resolution, 0);
+static IIO_DEVICE_ATTR(proximity_on_chip_ambient_infrared_supression,
+ S_IRUGO | S_IWUSR,
+ show_prox_infrared_supression,
+ store_prox_infrared_supression, 0);
+static IIO_DEVICE_ATTR(illuminance0_input, S_IRUGO, show_lux, NULL, 0);
+static IIO_DEVICE_ATTR(intensity_infrared_raw, S_IRUGO, show_ir, NULL, 0);
+static IIO_DEVICE_ATTR(proximity_raw, S_IRUGO, show_proxim_ir, NULL, 0);
+static IIO_DEVICE_ATTR(name, S_IRUGO, show_name, NULL, 0);
+
+#define ISL29018_DEV_ATTR(name) (&iio_dev_attr_##name.dev_attr.attr)
+#define ISL29018_CONST_ATTR(name) (&iio_const_attr_##name.dev_attr.attr)
+static struct attribute *isl29018_attributes[] = {
+ ISL29018_DEV_ATTR(name),
+ ISL29018_DEV_ATTR(range),
+ ISL29018_CONST_ATTR(range_available),
+ ISL29018_DEV_ATTR(adc_resolution),
+ ISL29018_CONST_ATTR(adc_resolution_available),
+ ISL29018_DEV_ATTR(proximity_on_chip_ambient_infrared_supression),
+ ISL29018_DEV_ATTR(illuminance0_input),
+ ISL29018_DEV_ATTR(intensity_infrared_raw),
+ ISL29018_DEV_ATTR(proximity_raw),
+ NULL
+};
+
+static const struct attribute_group isl29108_group = {
+ .attrs = isl29018_attributes,
+};
+
+static int isl29018_chip_init(struct i2c_client *client)
+{
+ struct isl29018_chip *chip = i2c_get_clientdata(client);
+ int status;
+ int new_adc_bit;
+ unsigned int new_range;
+
+ memset(chip->reg_cache, 0, sizeof(chip->reg_cache));
+
+ /* set defaults */
+ status = isl29018_set_range(client, chip->range, &new_range);
+ if (status < 0) {
+ dev_err(&client->dev, "Init of isl29018 fails\n");
+ return status;
+ }
+
+ status = isl29018_set_resolution(client, chip->adc_bit,
+ &new_adc_bit);
+
+ return 0;
+}
+
+static int __devinit isl29018_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct isl29018_chip *chip;
+ int err;
+
+ chip = kzalloc(sizeof(struct isl29018_chip), GFP_KERNEL);
+ if (!chip) {
+ dev_err(&client->dev, "Memory allocation fails\n");
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ i2c_set_clientdata(client, chip);
+ chip->client = client;
+
+ mutex_init(&chip->lock);
+
+ chip->range = 1000;
+ chip->adc_bit = 16;
+
+ err = isl29018_chip_init(client);
+ if (err)
+ goto exit_free;
+
+ chip->indio_dev = iio_allocate_device();
+ if (!chip->indio_dev) {
+ dev_err(&client->dev, "iio allocation fails\n");
+ goto exit_free;
+ }
+ chip->indio_dev->attrs = &isl29108_group;
+ chip->indio_dev->dev.parent = &client->dev;
+ chip->indio_dev->dev_data = (void *)(chip);
+ chip->indio_dev->driver_module = THIS_MODULE;
+ chip->indio_dev->modes = INDIO_DIRECT_MODE;
+ err = iio_device_register(chip->indio_dev);
+ if (err) {
+ dev_err(&client->dev, "iio registration fails\n");
+ goto exit_iio_free;
+ }
+
+ return 0;
+exit_iio_free:
+ iio_free_device(chip->indio_dev);
+exit_free:
+ kfree(chip);
+exit:
+ return err;
+}
+
+static int __devexit isl29018_remove(struct i2c_client *client)
+{
+ struct isl29018_chip *chip = i2c_get_clientdata(client);
+
+ dev_dbg(&client->dev, "%s()\n", __func__);
+ iio_device_unregister(chip->indio_dev);
+ kfree(chip);
+
+ return 0;
+}
+
+static const struct i2c_device_id isl29018_id[] = {
+ {"isl29018", 0},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, isl29018_id);
+
+static struct i2c_driver isl29018_driver = {
+ .class = I2C_CLASS_HWMON,
+ .driver = {
+ .name = "isl29018",
+ .owner = THIS_MODULE,
+ },
+ .probe = isl29018_probe,
+ .remove = __devexit_p(isl29018_remove),
+ .id_table = isl29018_id,
+};
+
+static int __init isl29018_init(void)
+{
+ return i2c_add_driver(&isl29018_driver);
+}
+
+static void __exit isl29018_exit(void)
+{
+ i2c_del_driver(&isl29018_driver);
+}
+
+module_init(isl29018_init);
+module_exit(isl29018_exit);
+
+MODULE_DESCRIPTION("ISL29018 Ambient Light Sensor driver");
+MODULE_LICENSE("GPL");
--
1.7.0.4
^ permalink raw reply related
* Re: Git over SMBFS
From: fREW Schmidt @ 2010-10-07 22:49 UTC (permalink / raw)
To: Casey Dahlin; +Cc: git
In-Reply-To: <20101007174006.GA31711@fearengine.rdu.redhat.com>
On Thu, Oct 7, 2010 at 12:40 PM, Casey Dahlin <cdahlin@redhat.com> wrote:
>
> On Tue, Oct 05, 2010 at 09:26:15PM -0500, fREW Schmidt wrote:
> > A coworker of mine is working on a project that is running on a
> > windows server. The project is in git, but we are having a lot of
> > trouble getting it to work at all. For example, if he merely does
> > (from his machine) "git checkout ." it seemingly times out after 680
> > files being checked out.
> >
> > Are there any settings we might be able to tweak that might make git
> > more tolerable of the latency involved in a network based checkout?
> >
>
> Sounds to me like the best way would be to make a local copy with
>
> git clone /path/to/cifs/mounted/project
>
> And then do your work on the local hard disk. Later, you can git-push
> back in to the cifs folder.
That's actually what we've been doing. I was just curious if there
were another way.
--
fREW Schmidt
http://blog.afoolishmanifesto.com
^ permalink raw reply
* RE: [PATCH v3 2/2] MAINTAINERS: Add Samsung S5P series FIMC maintainers
From: Kukjin Kim @ 2010-10-07 22:50 UTC (permalink / raw)
To: 'Kyungmin Park', linux-kernel
Cc: torvalds, akpm, rmk, m.szyprowski, pawel, t.fujak, s.nawrocki
In-Reply-To: <20100929090904.GA21199@july>
Kyungmin Park wrote:
>
> From: Kyungmin Park <kyungmin.park@samsung.com>
>
> Add Samsung S5P series FIMC(Camera Interface) maintainers
>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> v2:
> Write the right maintainers
>
> MAINTAINERS | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8ae1797..1e233d9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -977,6 +977,16 @@ L: linux-arm-kernel@lists.infradead.org
> S: Maintained
> F: arch/arm/mach-s5pv310/mach-universal_c210.c
>
> +ARM/SAMSUNG S5P SERIES FIMC SUPPORT
> +M: Kyungmin Park <kyungmin.park@samsung.com>
> +M: Sylwester Nawrocki <s.nawrocki@samsung.com>
> +L: linux-arm-kernel@lists.infradead.org
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +F: arch/arm/plat-s5p/dev-fimc*
> +F: arch/arm/plat-samsung/include/plat/*fimc*
Hi,
If required FIMC support maintainer, please remove above 2 lines...because
the plat-s5p/dev-fimc* are just platform data files and entirely removed
plat-samsung/include/plat/fimc.h header for removing platform code
dependency by Sylwester's FIMC patch.
> +F: drivers/media/video/s5p-fimc/
> +
> ARM/SHMOBILE ARM ARCHITECTURE
> M: Paul Mundt <lethal@linux-sh.org>
> M: Magnus Damm <magnus.damm@gmail.com>
> --
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH librdmacm] Fix autotools to include the necessary M4 files
From: Jason Gunthorpe @ 2010-10-07 22:50 UTC (permalink / raw)
To: Hefty, Sean, Linux RDMA list
Otherwise running autogen.sh with a new version of autotools and then
building on a system with an older version tends to explode.
Unfortunately this is sometimes necessary since the new version is
required by the package.
This is how GNU envisions this mess works at least..
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
Makefile.am | 1 +
configure.in | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
Sean - same story as for Roland, all your libraries need this patch,
can you apply it to all of them? Thanks.
diff --git a/Makefile.am b/Makefile.am
index 2668aa3..434cb6b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,6 +2,7 @@ INCLUDES = -I$(srcdir)/include
lib_LTLIBRARIES = src/librdmacm.la
+ACLOCAL_AMFLAGS = -I config
AM_CFLAGS = -g -Wall -D_GNU_SOURCE
src_librdmacm_la_CFLAGS = $(AM_CFLAGS)
diff --git a/configure.in b/configure.in
index 37d1851..e63211f 100644
--- a/configure.in
+++ b/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(librdmacm, 1.0.13, general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org)
AC_CONFIG_SRCDIR([src/cma.c])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE(librdmacm, 1.0.13)
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 2/2] device-assignment: Allow PCI to manage the option ROM
From: Michael S. Tsirkin @ 2010-10-07 22:45 UTC (permalink / raw)
To: Alex Williamson; +Cc: kvm, ddutile, chrisw
In-Reply-To: <1286472841.3020.56.camel@x201>
On Thu, Oct 07, 2010 at 11:34:01AM -0600, Alex Williamson wrote:
> On Thu, 2010-10-07 at 19:18 +0200, Michael S. Tsirkin wrote:
> > On Mon, Oct 04, 2010 at 03:26:30PM -0600, Alex Williamson wrote:
> > > --- a/hw/device-assignment.c
> > > +++ b/hw/device-assignment.c
> ...
> > > @@ -1644,58 +1621,64 @@ void add_assigned_devices(PCIBus *bus, const char **devices, int n_devices)
> > > */
> > > static void assigned_dev_load_option_rom(AssignedDevice *dev)
> > > {
> > > - int size, len, ret;
> > > - void *buf;
> > > + char name[32], rom_file[64];
> > > FILE *fp;
> > > - uint8_t i = 1;
> > > - char rom_file[64];
> > > + uint8_t val;
> > > + struct stat st;
> > > + void *ptr;
> > > +
> > > + /* If loading ROM from file, pci handles it */
> > > + if (dev->dev.romfile || !dev->dev.rom_bar)
> > > + return;
> > >
> > > snprintf(rom_file, sizeof(rom_file),
> > > "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
> > > dev->host.seg, dev->host.bus, dev->host.dev, dev->host.func);
> > >
> > > - if (access(rom_file, F_OK))
> > > + if (stat(rom_file, &st)) {
> > > return;
> > > + }
> > >
> >
> > Just a note that stat on the ROM sysfs file returns window size,
> > not the ROM size. So this allocates more ram than really necessary for
> > ROM. Real size is returned by fread.
> >
> > Do we care?
>
> That was my intention with using stat. I thought that by default the
> ROM BAR should match physical hardware, so even if the contents could be
> rounded down to a smaller size, we maintain the size of the physical
> device. To use the minimum size, the contents could be extracted using
> pci-sysfs and passed with the romfile option, or the ROM could be
> disabled altogether with the rombar=0 option. Sound reasonable?
> Thanks,
>
> Alex
For BAR size yes, but we do not need the buffer full of 0xff as it is
never accessed: let's have buffer size match real ROM, avoid wasting
memory: this can come up to megabytes easily.
Makes sense?
^ permalink raw reply
* 2.6.36-rc7: kernel panic with SECURITY_TOMOYO=y
From: Christian Kujau @ 2010-10-07 22:43 UTC (permalink / raw)
To: LKML; +Cc: takedakn, penguin-kernel
Hi,
I wanted to test Tomoyo, so I enabled CONFIG_SECURITY_TOMOYO in my
.config, wich enabled also:
+CONFIG_SECURITY=y
+CONFIG_SECURITYFS=y
+CONFIG_SECURITY_PATH=y
+CONFIG_SECURITY_TOMOYO=y
However, during boot the machine (PowerPC G4, 32 bit) now panics:
http://nerdbynature.de/bits/2.6.36-rc7/
I don't have a serial console, so I ran the image of the oops through some
OCR converter:
Kernel panic - not syncing: Profile uersion 0 is not supported
Call Trace:
[efB4fd60] [c0008c88] show_stack+0x48/0x168 (unreliable)
[ef84fda0] [c0375fe01 panic+0xa4/0x1ec
[ef84fdf0] [c01c5f30] tomoyo_close_control+0x0/0xa4
[efB4fe00] [c01cc2f0] tomoyo_load_policy+0xeB/0x11c
[ef84fe40] [c01cdd30] tomoyo_bprm_set_creds+0x84/0x88
[ef84fe50] [c01c37bc] security_bprm_set_creds+0x20/0x30
[ef84fe60] [c00a02cc] prepare_binprm+0x9e/0x128
[ef84fe90] [c00a0a10] do_execve+0x198/0x260
[ef84fed0] [e0009748] sys_execve+0x58/0x84
[efB4fef0] [c0010c1c] ret_from_syscall+0x0/0x38
--- Exception: C01 at kernel_execve+0x8/0x14
LR = init_post+0x7c/0x138
[ef84ffb0] [c000405c] init_post+0x20/0x138 (unreliable)
[cfB4ffd0] [c043a25c] kernel_init+0x13c/0x174
[ef84fff0] [c0010974] kernel_thread+0x4c/0x68
Rebooting in 180 seconds..
(Don't trust the numbers in the first two rows though (the ones in "[]"
brackets) the other ones should be fine)
I've not bisected the issue yet (compiling one kernel takes about ~40min
on this box), any ideas what might have caused this?
Christian.
--
BOFH excuse #380:
Operators killed when huge stack of backup tapes fell over.
^ permalink raw reply
* + ipc-initialize-structure-memory-to-zero-for-compat-functions.patch added to -mm tree
From: akpm @ 2010-10-07 22:51 UTC (permalink / raw)
To: mm-commits; +Cc: drosenberg, arnd, manfred
The patch titled
ipc: initialize structure memory to zero for compat functions
has been added to the -mm tree. Its filename is
ipc-initialize-structure-memory-to-zero-for-compat-functions.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: ipc: initialize structure memory to zero for compat functions
From: Dan Rosenberg <drosenberg@vsecurity.com>
This takes care of leaking uninitialized kernel stack memory to
userspace from non-zeroed fields in structs in compat ipc functions.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
ipc/compat.c | 6 ++++++
ipc/compat_mq.c | 5 +++++
2 files changed, 11 insertions(+)
diff -puN ipc/compat.c~ipc-initialize-structure-memory-to-zero-for-compat-functions ipc/compat.c
--- a/ipc/compat.c~ipc-initialize-structure-memory-to-zero-for-compat-functions
+++ a/ipc/compat.c
@@ -241,6 +241,8 @@ long compat_sys_semctl(int first, int se
struct semid64_ds __user *up64;
int version = compat_ipc_parse_version(&third);
+ memset(&s64, 0, sizeof(s64));
+
if (!uptr)
return -EINVAL;
if (get_user(pad, (u32 __user *) uptr))
@@ -421,6 +423,8 @@ long compat_sys_msgctl(int first, int se
int version = compat_ipc_parse_version(&second);
void __user *p;
+ memset(&m64, 0, sizeof(m64));
+
switch (second & (~IPC_64)) {
case IPC_INFO:
case IPC_RMID:
@@ -594,6 +598,8 @@ long compat_sys_shmctl(int first, int se
int err, err2;
int version = compat_ipc_parse_version(&second);
+ memset(&s64, 0, sizeof(s64));
+
switch (second & (~IPC_64)) {
case IPC_RMID:
case SHM_LOCK:
diff -puN ipc/compat_mq.c~ipc-initialize-structure-memory-to-zero-for-compat-functions ipc/compat_mq.c
--- a/ipc/compat_mq.c~ipc-initialize-structure-memory-to-zero-for-compat-functions
+++ a/ipc/compat_mq.c
@@ -53,6 +53,9 @@ asmlinkage long compat_sys_mq_open(const
void __user *p = NULL;
if (u_attr && oflag & O_CREAT) {
struct mq_attr attr;
+
+ memset(&attr, 0, sizeof(attr));
+
p = compat_alloc_user_space(sizeof(attr));
if (get_compat_mq_attr(&attr, u_attr) ||
copy_to_user(p, &attr, sizeof(attr)))
@@ -127,6 +130,8 @@ asmlinkage long compat_sys_mq_getsetattr
struct mq_attr __user *p = compat_alloc_user_space(2 * sizeof(*p));
long ret;
+ memset(&mqstat, 0, sizeof(mqstat));
+
if (u_mqstat) {
if (get_compat_mq_attr(&mqstat, u_mqstat) ||
copy_to_user(p, &mqstat, sizeof(mqstat)))
_
Patches currently in -mm which might be from drosenberg@vsecurity.com are
linux-next.patch
ipc-initialize-structure-memory-to-zero-for-compat-functions.patch
^ permalink raw reply
* Re: [RFC v2] mac80211: fix possible null-pointer dereference
From: Johannes Berg @ 2010-10-07 22:54 UTC (permalink / raw)
To: Steve deRosier
Cc: Christian Lamparter, John W. Linville, Luis Carlos Cobo,
linux-wireless, Javier Cardona
In-Reply-To: <AANLkTinCkWGs_KMz+QBUw2J5HUVU2hK1+8kVDr_PNZwP@mail.gmail.com>
On Thu, 2010-10-07 at 15:38 -0700, Steve deRosier wrote:
> Javier and I reviewed the patch and it definitely fixes a potential
> problem and is correct. Furthermore, applied to wireless-testing
> head, it passes all of our cases in our test bed.
>
> I think it's good to go.
Err, are you positive? I think the code there is correct, apart from the
fact that it does no validation of
mgmt->u.action.u.plink_action.action_code whatsoever which may allow all
kinds of abuse :)
The only action that's valid w/o having a station entry for the peer is
PLINK_OPEN, which makes perfect sense.
johannes
^ permalink raw reply
* Re: How to modify /etc/network/interfaces file in a OE recipe
From: Gary Thomas @ 2010-10-07 22:54 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <3ADCCD33-6EA5-43FA-84EE-31D6B7C5A005@mac.com>
On 10/07/2010 03:11 PM, Elvis Dowson wrote:
> Hi,
> Would someone be able to help me with modifying an omap3-console-image recipe, such that in the final image, the /etc/network/interfaces file gets edited as follows
>
> #auto eth0 <- remove # sign ( auto eth0 )
> #iface eth0 inet dhcp <- remove # sign ( iface eth0 inet dhcp )
> #iface eth1 inet dhcp
>
> I am using a Gumstix Overo + Chestnut43 expansion board, which has an inbuilt wired ethernet interface. I have to make this modification manually, to enable this interface each time. However, if I can modify the OE recipe somehow to do this it would be great. I know it can be done, but I don't know where to start and which file to modify.
Add the file the way you like it to .../openembedded/recipes/netbase/netbase/overo
and rebuild netbase. Use the beagleboard as an example.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* [PATCH] dma/timberdale: simplify conditional
From: Nicolas Kaiser @ 2010-10-07 22:48 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-kernel
Simplify: ((a && b) || (!a && !b)) => (a == b)
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
---
drivers/dma/timb_dma.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
index 2ec1ed5..3b88a4e 100644
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -759,7 +759,7 @@ static int __devinit td_probe(struct platform_device *pdev)
pdata->channels + i;
/* even channels are RX, odd are TX */
- if (((i % 2) && pchan->rx) || (!(i % 2) && !pchan->rx)) {
+ if ((i % 2) == pchan->rx) {
dev_err(&pdev->dev, "Wrong channel configuration\n");
err = -EINVAL;
goto err_tasklet_kill;
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH] CHROMIUM: i915: Initialize panel timing registers if VBIOS did not.
From: Chris Wilson @ 2010-10-07 22:55 UTC (permalink / raw)
To: Bryan Freed, Jesse Barnes, Eric Anholt, intel-gfx, Olof Johansson,
Mandeep
In-Reply-To: <AANLkTikoPjDs-RNs+nvOJUO5UWHedGjRT1Ee7kuDyVdO@mail.gmail.com>
On Thu, 7 Oct 2010 15:48:14 -0700, Bryan Freed <bfreed@chromium.org> wrote:
> The time between start of the pixel clock and backlight enable is a basic
> panel timing constraint. If no VBIOS Table is found, and the Panel Power
> On/Off registers are found to be 0, assume we are booting without VBIOS
> initialization and set these registers to something reasonable.
IIRC, the panel sequence registers are meant to be stored in the VBIOS. So
if we add the parsing of those to the driver and add the defaults to
init_vbt_default() then we can check whether PP_ON_DELAYS is valid upon
device init (module load and resume) and fixup in case the BIOS does not.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH] ARM: imx serial driver: fix resume
From: Andrew Morton @ 2010-10-07 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286384236-4241-1-git-send-email-daniel@caiaq.de>
On Wed, 6 Oct 2010 18:57:16 +0200
Daniel Mack <daniel@caiaq.de> wrote:
> From: Volker Ernst <volker.ernst@txtr.com>
>
> I just came across a bug in the IMX31 serial driver which is still
> present in the newest kernels and which prevents successful
> resume-operation for the IMX31 serial ports.
>
> What happens is that in "drivers/serial/imx.c" on resume function
> "serial_imx_resume" gets called. This function in turn calls
> "uart_resume_port" (in the generic serial driver "serial_core.c"),
> which in turn calls "imx_start_tx" in "imx.c" (in case the SIO-port
> was really suspended) which in turn calls "imx_transmit_buffer".
>
> However calling "imx_transmit_buffer" with an empty TX-fifo (as is
> usually the case) will result in the serial port starting to transmit
> (actually the old [already sent] tx-buffer), as there is no check if
> the tx-buffer is empty before starting to feed tx-fifo-data to the
> serial port hardware.
>
> Signed-off-by: Volker Ernst <volker.ernst@txtr.com>
> Cc: Daniel Mack <daniel@caiaq.de>
This should have been Signed-off-by:, as you were on the patch delivery
path.
I made that change to my copy of the patch, thanks.
> Cc: Andy Green <andy@warmcat.com>
^ permalink raw reply
* Re: kgdb errors with serial console
From: Elvis Dowson @ 2010-10-07 22:55 UTC (permalink / raw)
To: Jason Wessel; +Cc: Linux Kernel Mailing List, Linux OMAP Mailing List
In-Reply-To: <4CAE4BB6.7080509@windriver.com>
Hi Jason,
On Oct 8, 2010, at 2:37 AM, Jason Wessel wrote:
>
> Looks to me like you did not activate the kernel debugger before using
> gdb to enter, because the gdb you are using is not going to send the
> "sysrq g" sequence.
Will it not be activated and wait with the following boot args?
mmcargs=setenv bootargs console=${console} vram=12M omapfb.vram=0:4M omapfb.mode=dvi:${dvimode} omapdss.def_disp=${defaultdisplay} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait kgdb=${console} kgdboc=${console} kgdbwait
After specific the following commands in .gdbinit, I am able to get properly formatted messages in the Eclipse IDE
set remotebaud 115200
set remoteflow 0
set debug remote 1
Best regards,
Elvis
^ permalink raw reply
* Re: [PATCH,V2 0/6] libtool 2.4 upgrade
From: Graham Gower @ 2010-10-07 22:56 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTinatBiNfBgMiKPzDGa+rac7FjQU02hBBammKGQE@mail.gmail.com>
I've done a bitbake -k world with this patch set. Below is a list of
tasks that were found to fail with the patch, but succeeded in my last
world build without the patch (about a week ago).
atk-1.30.0-r0: do_compile:
blipomoko-0.2.99+gitr0+73ffa20d535d7bcf693981ac00d488db72dd2f68-r0: do_compile:
ccrtp-1.7.0-r0: do_compile:
clamav-0.96.3-r5.0: do_compile:
clish-0.7.3-r1: do_compile:
cwiid-0.6.00+svnr192-r0: do_compile:
dbus-hlid-1_1.0.1+gitr0+5df7f49fe8881804aaab544a569fd164c3e93afb-r0:
do_configure:
devilspie-0.22-r0: do_configure:
enchant-1.6.0-r2: do_compile:
exiv2-0.20-r0: do_compile:
fluidsynth-1.0.8-r1: do_compile:
fso-monitord-1_0.0.0+gitr0+b4ae1e9b10e710042624c2cf1a15b91a7d5b1d44-r0:
do_configure:
geda-xgsch2pcb-0.1.2-r2: do_configure:
glrr-20050529-r0: do_compile:
gputty-0.9.8-r0: do_compile:
gstreamer-0.10.30-r0: do_compile:
ibrdtn-0.4.2-r0: do_compile:
ido-0.1.6-r0: do_compile:
irdadump-0.9.16-r1: do_install:
json-glib-0.10.4-r0: do_compile:
konqueror-embedded-20070316-r7: do_configure:
libecj-bootstrap-3.6-r0: do_compile:
libgpod-0.7.92-r0: do_compile:
libsdl-ttf-2.0.9-r0: do_compile:
libvpx-0.9.1-r4.0: do_configure:
libwmf-0.2.8.4-r1: do_compile:
lxpanel-0.5.5-r0: do_compile:
mediatomb-0.11.0-r1: do_compile:
moko-gtk-engine-0.1.0+svnr4734-r0: do_compile:
mokoeightball-0.2+svnr45-r0: do_compile:
mousepad-0.2.16-r3: do_configure:
neolight-1.4.0+svnr16-r1: do_compile:
nxcompext-3.4.0-1-r0: do_compile:
openldap-2.4.23-r1: do_compile:
oprofile-0.9.6-r13.0: do_compile:
orrery-2.7-r0: do_compile:
piccontrol-0.4-r1: do_compile:
python-pygobject-native-1_2.20.0-r1: do_compile:
refdbg-1.2-r0: do_compile:
shr-today-0.0.1+gitr0+7b69649a9df0e85f0c0f7985fd1d93543c3b11e2-r3: do_compile:
telepathy-gabble-0.7.27-r0: do_configure:
toppler-1.1.3-r0: do_compile:
vmedit-0.02-r1: do_compile:
xapian-bindings-python-1.0.14-r0: do_compile:
gst-plugin-bc-0.10.1.1-r1+gitre14e249ef6cb67e91be9198b71efc61eb84c11b5:
do_configure:
^ permalink raw reply
* + arm-imx-serial-driver-fix-resume.patch added to -mm tree
From: akpm @ 2010-10-07 22:56 UTC (permalink / raw)
To: mm-commits; +Cc: volker.ernst, andy, daniel, greg, s.hauer
The patch titled
ARM: imx serial driver: fix resume
has been added to the -mm tree. Its filename is
arm-imx-serial-driver-fix-resume.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: ARM: imx serial driver: fix resume
From: Volker Ernst <volker.ernst@txtr.com>
I just came across a bug in the IMX31 serial driver which is still present
in the newest kernels and which prevents successful resume-operation for
the IMX31 serial ports.
What happens is that in "drivers/serial/imx.c" on resume function
"serial_imx_resume" gets called. This function in turn calls
"uart_resume_port" (in the generic serial driver "serial_core.c"), which
in turn calls "imx_start_tx" in "imx.c" (in case the SIO-port was really
suspended) which in turn calls "imx_transmit_buffer".
However calling "imx_transmit_buffer" with an empty TX-fifo (as is usually
the case) will result in the serial port starting to transmit (actually
the old [already sent] tx-buffer), as there is no check if the tx-buffer
is empty before starting to feed tx-fifo-data to the serial port hardware.
Signed-off-by: Volker Ernst <volker.ernst@txtr.com>
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Andy Green <andy@warmcat.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/serial/imx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/serial/imx.c~arm-imx-serial-driver-fix-resume drivers/serial/imx.c
--- a/drivers/serial/imx.c~arm-imx-serial-driver-fix-resume
+++ a/drivers/serial/imx.c
@@ -328,13 +328,13 @@ static inline void imx_transmit_buffer(s
struct circ_buf *xmit = &sport->port.state->xmit;
while (!(readl(sport->port.membase + UTS) & UTS_TXFULL)) {
+ if (uart_circ_empty(xmit))
+ break;
/* send xmit->buf[xmit->tail]
* out the port here */
writel(xmit->buf[xmit->tail], sport->port.membase + URTX0);
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
sport->port.icount.tx++;
- if (uart_circ_empty(xmit))
- break;
}
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
_
Patches currently in -mm which might be from volker.ernst@txtr.com are
arm-imx-serial-driver-fix-resume.patch
^ permalink raw reply
* Re: phandle patch review?
From: Grant Likely @ 2010-10-07 23:01 UTC (permalink / raw)
To: sparclinux
On Tue, Oct 5, 2010 at 1:29 PM, Andres Salomon <dilinger@queued.net> wrote:
> On Tue, 28 Sep 2010 14:59:53 -0700
> Andres Salomon <dilinger@queued.net> wrote:
>
>> On Wed, 29 Sep 2010 05:39:59 +0900
>> Grant Likely <grant.likely@secretlab.ca> wrote:
>>
>> > On Wed, Sep 29, 2010 at 4:48 AM, Andres Salomon
>> > <dilinger@queued.net> wrote:
>> > > Hi Grant,
>> > >
>> > > I'm assuming the sparc patches can go through your tree as well.
>> > > Please let me know if anything else needs to happen, now that we
>> > > have an ACK from davem.
>> >
>> > Did the phandle -> types.h issues get sorted out? I can't remember.
>>
>> The relevant thread was here:
>> https://patchwork.kernel.org/patch/140991/
>>
>> I found Sam's initial comment unclear, so I asked for clarification
>> (specifying that we didn't need phandle to be exported to userspace);
>> his response was:
>>
>> "So the above looks good considerign that userspace
>> so far does not require ihanlde/phandle."
>>
>> I left it open-ended regarding whether or not userspace might want
>> phandle/ihandle to be exported (that's more a question for you
>> flat devicetree folks :) , but for my purposes not having it exposed
>> to userspace is just fine.
>
>
>
> So yeah, please let me know if there's anything outstanding that I
> missed that would keep the patches from getting merged.
Okay, I'm confused. As you say, asm/openprom.h is exported. None of
openprom.h is protect with __KERNEL__, so all of it gets exposed to
userspace. You're patch adds phandle to the __KERNEL__ protected
section of types.h, which means that it is unavailable to userspace.
In which case anything from userspace including asm/openprom.h will
fail to compile, or am I missing something?
g.
^ permalink raw reply
* PCH eDP fixes
From: Jesse Barnes @ 2010-10-07 23:01 UTC (permalink / raw)
To: intel-gfx
Here's the set of PCH eDP fixes I came up with once I received my Sony
Vaio. I found a few, non-PCH issues in the process, and took the
opportunity to enhance our eDP support to avoid most of the DP training
if the VBIOS gives us good data.
This patchset is against ickle's drm-intel-next branch as of a few hours
ago, and is working on my test machine. Before I rebased, I had success
reports from several users on bug
https://bugs.freedesktop.org/show_bug.cgi?id=29141. The key change
there was to work around a newly discovered Ironlake panel power
sequencing bug (need to disable clock gating for the panel power
sequencing unit); before that change, panel bringup was very
intermittent.
Thanks,
Jesse
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.