* [PATCH] ARM pca-a-l1: fix board_init
From: Sascha Hauer @ 2012-01-17 10:23 UTC (permalink / raw)
To: barebox; +Cc: Juergen Kilb
board_init is now called omap3_board_init. broken since:
commit 494a12f703c33f80fe96e2a728545c490347eceb
Author: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date: Sat Jan 14 15:51:05 2012 +0100
omap3: move platform lowlevel init to mach-omap
this will allow to switch omap3 to standard organisation
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boards/phycard-a-l1/Makefile | 1 -
arch/arm/boards/phycard-a-l1/lowlevel.c | 39 -------------------------------
arch/arm/boards/phycard-a-l1/pca-a-l1.c | 2 +-
3 files changed, 1 insertions(+), 41 deletions(-)
delete mode 100644 arch/arm/boards/phycard-a-l1/lowlevel.c
diff --git a/arch/arm/boards/phycard-a-l1/Makefile b/arch/arm/boards/phycard-a-l1/Makefile
index cb0106b..db48b6d 100644
--- a/arch/arm/boards/phycard-a-l1/Makefile
+++ b/arch/arm/boards/phycard-a-l1/Makefile
@@ -18,5 +18,4 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
-obj-$(CONFIG_MACH_DO_LOWLEVEL_INIT) += lowlevel.o
obj-y += pca-a-l1.o
diff --git a/arch/arm/boards/phycard-a-l1/lowlevel.c b/arch/arm/boards/phycard-a-l1/lowlevel.c
deleted file mode 100644
index bffbb08..0000000
--- a/arch/arm/boards/phycard-a-l1/lowlevel.c
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * (C) Copyright 2011
- * Phytec Messtechnik GmbH <www.phytec.de>
- * Juergen Kilb <j.kilb@phytec.de>
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * 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., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-#include <common.h>
-#include <asm/barebox-arm.h>
-#include <mach/sdrc.h>
-#include <mach/omap3-silicon.h>
-
-void __naked board_init_lowlevel(void)
-{
- uint32_t r;
-
- /* setup a stack */
- r = OMAP_SRAM_STACK;
- __asm__ __volatile__("mov sp, %0" : : "r"(r));
-
- board_init();
-
- board_init_lowlevel_return();
-}
diff --git a/arch/arm/boards/phycard-a-l1/pca-a-l1.c b/arch/arm/boards/phycard-a-l1/pca-a-l1.c
index 7b127f3..11e8638 100644
--- a/arch/arm/boards/phycard-a-l1/pca-a-l1.c
+++ b/arch/arm/boards/phycard-a-l1/pca-a-l1.c
@@ -224,7 +224,7 @@ static void pcaal1_mux_config(void)
*
* @return void
*/
-void board_init(void)
+void omap3_board_init(void)
{
int in_sdram = running_in_sdram();
--
1.7.8.3
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* [U-Boot] [PATCH v2] configs: Remove CONFIG_NET_MULTI from board files
From: Stefano Babic @ 2012-01-17 10:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326639788-6085-1-git-send-email-festevam@gmail.com>
On 15/01/2012 16:03, Fabio Estevam wrote:
> CONFIG_NET_MULTI is not used anymore, so remove it from board files.
>
> Cc: Marek Vasut <marek.vasut@gmail.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Kumar Gala <kumar.gala@freescale.com>
> Cc: Sandeep Paulraj <s-paulraj@ti.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915: set AUD_CONFIG N_value_index for DisplayPort
From: Daniel Vetter @ 2012-01-17 10:22 UTC (permalink / raw)
To: Wu Fengguang
Cc: Keith Packard, Daniel Vetter, Takashi Iwai,
intel-gfx@lists.freedesktop..., Michal Marek, LKML,
Robert Lemaire
In-Reply-To: <20120116230809.GA7837@localhost>
On Tue, Jan 17, 2012 at 07:08:09AM +0800, Wu Fengguang wrote:
> On Mon, Jan 16, 2012 at 12:44:43PM -0800, Keith Packard wrote:
> > On Mon, 16 Jan 2012 21:26:18 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > > Keith, does this address your concern and this patch is r-b: Keith or do
> > > we want an
> > >
> > > } else {
> > > I915_WRITE(aud_config, 0);
> > > }
> > >
> > > for paranoia?
> >
> > I think we want this added, just to be sure we set the configuration
> > correctly in all cases; it's easy to imagine moving from DP to HDMI and
> > leaving this bit set.
>
> Ah good point! Here is the updated patch.
>
> ---
> Subject: drm/i915: set AUD_CONFIG N_value_index for DisplayPort
> Date: Fri Jan 06 14:41:31 CST 2012
>
> It should be programmed to "0" for HDMI or "1" for DisplayPort.
>
> This enables DisplayPort audio for
>
> - HP EliteBook 8460p
> (whose BIOS does not set the N_value_index bit for us)
>
> - DisplayPort monitor hot plugged after boot
> (otherwise most BIOS will fill the N_value_index bit for us)
>
> Tested-by: Robert Lemaire <rlemaire@suse.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
I've tried to apply this patch but it has a conflict in i915_reg.h (with
the SOL reset stuff). Care to rebase and resend? Also, git patches as
produced by git format-patch highly preferred.
Thanks, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [PATCH 1/2 v2] add config to check if the size of barebox exceed the target size
From: Sascha Hauer @ 2012-01-17 10:21 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: barebox
In-Reply-To: <1326730793-2818-1-git-send-email-plagnioj@jcrosoft.com>
On Mon, Jan 16, 2012 at 05:19:52PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> CONFIG_BAREBOX_MAX_IMAGE_SIZE will allow to detected silent oversize result
>
> if 0x0 the size will not been checked
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
> v2:
>
> change to CONFIG_BAREBOX_MAX_IMAGE_SIZE
> use default as 0xffffffff
>
> Best Regards,
> J.
> Makefile | 7 +++++++
> common/Kconfig | 8 ++++++++
> 2 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d8e685e..12fa192 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -659,6 +659,13 @@ OBJCOPYFLAGS_barebox.bin = -O binary
>
> barebox.bin: barebox FORCE
> $(call if_changed,objcopy)
> + size=`stat -c%s $@`; \
> + max_size=`printf "%d" $(CONFIG_BAREBOX_MAX_IMAGE_SIZE)`; \
> + if [ $$size -gt $$max_size ] ; \
> + then \
> + echo "$@ size $$size > of the maximum size $$max_size"; \
> + exit 1 ; \
> + fi
added a '@' while applying to make this check quiet.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH 3/3] pango.inc: add directory "/etc/pango"
From: Koen Kooi @ 2012-01-17 10:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1sq-cbZpPP3jxf1pUw_DaNGzY0QPqho4zmJN-Dnb9VqVPQ@mail.gmail.com>
Op 17 jan. 2012, om 10:11 heeft Khem Raj het volgende geschreven:
> On Sun, Jan 15, 2012 at 8:34 PM, Saul Wold <sgw@linux.intel.com> wrote:
>> On 01/12/2012 11:06 PM, Xiaofeng Yan wrote:
>>>
>>> From: Xiaofeng Yan<xiaofeng.yan@windriver.com>
>>>
>>> Command "pango-querymodules> /etc/pango/pango.modules" can't work when \
>>> starting up yocto because of no directory "/etc/pango". It will cause \
>>> messy code when gtk-demo running.
>>>
>>> [YOCTO #1674]
>>>
>>> Signed-off-by: Xiaofeng Yan<xiaofeng.yan@windriver.com>
>>> ---
>>> meta/recipes-graphics/pango/pango.inc | 7 ++++++-
>>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/meta/recipes-graphics/pango/pango.inc
>>> b/meta/recipes-graphics/pango/pango.inc
>>> index b428b9d..06db327 100644
>>> --- a/meta/recipes-graphics/pango/pango.inc
>>> +++ b/meta/recipes-graphics/pango/pango.inc
>>> @@ -46,6 +46,11 @@ fi
>>>
>>> }
>>>
>>> +# Command "pango-querymodules> /etc/pango/pango.modules" needs this
>>> directory.
>>> +do_install_prepend() {
>>> + install -d ${D}/${sysconfdir}/pango
>>> +}
>>> +
>>> python populate_packages_prepend () {
>>> prologue = d.getVar("postinst_prologue", 1)
>>>
>>> @@ -54,6 +59,6 @@ python populate_packages_prepend () {
>>> do_split_packages(d, modules_root, '^pango-(.*)\.so$',
>>> 'pango-module-%s', 'Pango module %s', prologue + 'pango-querymodules>
>>> /etc/pango/pango.modules')
>>> }
>>>
>>> -FILES_${PN} = "/etc/pango/* ${bindir}/* ${libdir}/libpango*${SOLIBS}"
>>> +FILES_${PN} += "${bindir}/* ${libdir}/libpango*${SOLIBS}"
>>
>> This can actually be removed completed since the default for FILES_${PN}
>> includes bindir/* and libdir/lib*${SOLIBS}
>>
>> I fixed this up in my testing area.
>>
>
> Saul
>
> This seems wrong to me. Since now all the modules will also be bundled in $PN
> whereas you want them in pango-modules-* packages since
> populate_packages_prepend has nothing left to generate out modules
> packages so please reintroduce the FILES_${PN} as it was (note that it
> was overwriting the defaults
> and not appending to it.)
The original problem can also be solved by doing the mkdir in the postinst prologue
^ permalink raw reply
* Re: [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Viresh Kumar @ 2012-01-17 10:19 UTC (permalink / raw)
To: Jassi Brar
Cc: vinod.koul@intel.com, Pratyush ANAND, Rajeev KUMAR,
linux@arm.linux.org.uk, Bhupesh SHARMA, Armando VISCONTI,
linus.walleij@linaro.org, Mirko GARDI,
linux-kernel@vger.kernel.org, Vipin KUMAR, Shiraz HASHIM,
Amit VIRDI, Vipul Kumar SAMAR, viresh.linux@gmail.com,
Deepak SIKRI, Bhavna YADAV, dan.j.williams@intel.com,
linux-arm-kernel@lists.infradead.org, Vincenzo FRASCINO
In-Reply-To: <CAJe_ZhfYgz5LEO7VqOJ8Qo+PZWrMNNvdfvCGQWMMq-TrbmL+xw@mail.gmail.com>
On 1/17/2012 3:40 PM, Jassi Brar wrote:
> In case at hand since most likely only valid values are power of 2,
> maybe you can do
> maxburst = ffs(maxburst) - 1
Thanks.
--
viresh
^ permalink raw reply
* Re: [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Viresh Kumar @ 2012-01-17 10:19 UTC (permalink / raw)
To: Linus Walleij
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linux@arm.linux.org.uk, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Armando VISCONTI,
Shiraz HASHIM, Vipin KUMAR, Rajeev KUMAR, Deepak SIKRI,
Vipul Kumar SAMAR, Amit VIRDI, Pratyush ANAND, Bhupesh SHARMA,
viresh.linux@gmail.com, Bhavna YADAV, Vincenzo FRASCINO,
Mirko GARDI
In-Reply-To: <4F153C33.5060805@st.com>
On 1/17/2012 2:45 PM, Viresh Kumar wrote:
> On 1/17/2012 2:19 PM, Linus Walleij wrote:
>> > Are you looking for ffs() from <linus/bitops.h>?
>> >
>> > find-first-set (the include boils down to include/asm-generic/bitops/ffs.h
>> > if you want to check the implementation).
> Thanks, but it might not solve the issue. :(
> Actually this will retain the first Least Significant Bit (which is 1)
> and will mark all other zero. So it will give output 0b10 for 0b110
>
Oops!! I didn't looked at fls in the implementation. :(
You are right. This will solve my issue.
--
viresh
^ permalink raw reply
* [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Viresh Kumar @ 2012-01-17 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJe_ZhfYgz5LEO7VqOJ8Qo+PZWrMNNvdfvCGQWMMq-TrbmL+xw@mail.gmail.com>
On 1/17/2012 3:40 PM, Jassi Brar wrote:
> In case at hand since most likely only valid values are power of 2,
> maybe you can do
> maxburst = ffs(maxburst) - 1
Thanks.
--
viresh
^ permalink raw reply
* Git server
From: Damien Churchill @ 2012-01-17 10:19 UTC (permalink / raw)
To: linux-bcache-u79uwXL29TY76Z2rM5mHXA
Hi Kent,
The git web interface is down at the moment in case you weren't aware.
^ permalink raw reply
* [PATCH] mac80211: Remove dummy STA on deauth
From: Pontus Fuchs @ 2012-01-17 10:19 UTC (permalink / raw)
To: linux-wireless
Under certain conditions a dummy STA entry could be left in the
station list. This causes subsequent connection attempts to fail.
Logs look like this:
authenticate with 00:23:69:aa:dd:7b (try 1)
authenticated
failed to insert Dummy STA entry for the AP (error -17)
deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)
Fix this by making sure to remove the dummy STA on deauth.
Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
---
The problem was introduced by the following commit added in v3.1:
mac80211: fix race condition between assoc_done and first EAP packet
This problem is fixed in the recent patch series from
Johannes Berg: [PATCH 0/8] more station handling refactoring
If you need a smaller fix this might fit you.
net/mac80211/mlme.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index ecb4c84..8bd8d4d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2751,6 +2751,7 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata,
struct ieee80211_local *local = sdata->local;
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct ieee80211_work *wk;
+ struct sta_info *dummy;
u8 bssid[ETH_ALEN];
bool assoc_bss = false;
@@ -2810,6 +2811,11 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata,
if (assoc_bss)
sta_info_flush(sdata->local, sdata);
+ /* Make sure to remove dummy STA if it's there */
+ dummy = sta_info_get_bss_rx(sdata, req->bss->bssid);
+ if (dummy)
+ sta_info_destroy_addr(sdata, req->bss->bssid);
+
mutex_lock(&sdata->local->mtx);
ieee80211_recalc_idle(sdata->local);
mutex_unlock(&sdata->local->mtx);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Viresh Kumar @ 2012-01-17 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F153C33.5060805@st.com>
On 1/17/2012 2:45 PM, Viresh Kumar wrote:
> On 1/17/2012 2:19 PM, Linus Walleij wrote:
>> > Are you looking for ffs() from <linus/bitops.h>?
>> >
>> > find-first-set (the include boils down to include/asm-generic/bitops/ffs.h
>> > if you want to check the implementation).
> Thanks, but it might not solve the issue. :(
> Actually this will retain the first Least Significant Bit (which is 1)
> and will mark all other zero. So it will give output 0b10 for 0b110
>
Oops!! I didn't looked at fls in the implementation. :(
You are right. This will solve my issue.
--
viresh
^ permalink raw reply
* [PATCH v2] I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
From: Shubhrajyoti D @ 2012-01-17 10:18 UTC (permalink / raw)
To: linux-arm-kernel
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
Rebased to Kevin's tree i2c misc branch
Tested on omsp4sdp and omap3sdp
drivers/i2c/busses/i2c-omap.c | 75 +++++++++++++++++-----------------------
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..914bed8 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
}
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev->bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev->syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
- * Don't write to this register if the IE state is 0 as it can
- * cause deadlock.
- */
- if (dev->iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev->rev < OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev->dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev->iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (_dev->iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH v2] I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
From: Shubhrajyoti D @ 2012-01-17 10:18 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-l0cyMroinI0, Shubhrajyoti D
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D <shubhrajyoti-l0cyMroinI0@public.gmane.org>
---
Rebased to Kevin's tree i2c misc branch
Tested on omsp4sdp and omap3sdp
drivers/i2c/busses/i2c-omap.c | 75 +++++++++++++++++-----------------------
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..914bed8 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
}
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev->bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev->syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
- * Don't write to this register if the IE state is 0 as it can
- * cause deadlock.
- */
- if (dev->iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev->rev < OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev->dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev->iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (_dev->iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
return 0;
}
--
1.7.1
^ permalink raw reply related
* [RFC PATCH] ARM: new architecture for Energy Micro's EFM32 Cortex-M3 SoCs
From: Uwe Kleine-König @ 2012-01-17 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120116174039.GD32049@n2100.arm.linux.org.uk>
Hello Russell,
I'm glad you're replying though my tree was just intended to show a
prove of concept, not a tree ready to be merged.
On Mon, Jan 16, 2012 at 05:40:39PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 16, 2012 at 05:29:33PM +0100, Uwe Kleine-K?nig wrote:
> > On Wed, Dec 21, 2011 at 07:31:56PM +0200, Ohad Ben-Cohen wrote:
> > > Hi Uwe,
> > >
> > > 2011/12/21 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > > > If you're interested in the details I can publish my tree I think.
> > >
> > > Definitely interested - it could be very nice if you can publish that tree.
> > OK, it's online now at
> >
> > http://git.pengutronix.de/?p=ukl/linux-2.6.git;a=shortlog;h=refs/heads/efm32
> > git://git.pengutronix.de/git/ukl/linux.git efm32
> >
> > Please note that this is work in progress and has some rough edges. ...
> > but at least it boots on my machine.
>
> Some of your patches seem weird, like this:
>
> for (i = 0; i < ARRAY_SIZE(cache_policies); i++) {
> - int len = strlen(cache_policies[i].policy);
> -
> - if (memcmp(p, cache_policies[i].policy, len) == 0) {
> + if (strcmp(p, cache_policies[i].policy) == 0) {
>
> Please compare the two, specifically how many bytes of the strings in
> each case are compared. I think you'll find it's not an equivalent
> change, and you need to discard the patch.
OK, so you say it is intended that I can do
early_cachepolicy("writebackyourmother");
with the same result as
early_cachepolicy("writeback");
? Maybe a comment would be great to have in place then about
why this is done. I couldn't find a user apart from
early_param("cachepolicy", early_cachepolicy);
and this parameter isn't described in
Documentation/kernel-parameters.txt.
I would understand if only strlen(p) bytes were checked which would
allow to shorten the parameter. (But then
cachepolicy=
would have a meaning (though I didn't test -- I think it would select
uncached) which is strange.) All in all I put the patch there as a
reminder for me to ask if everything the function does is intended.
> This looks buggy:
> +#if defined(CONFIG_CPU_V7M)
> + .macro setmode, mode, reg
> + .endm
> +#elif defined(CONFIG_THUMB2_KERNEL)
> .macro setmode, mode, reg
> mov \reg, #\mode
> msr cpsr_c, \reg
>
> as it does nothing about the interrupt mask.
right, good catch.
> The VFP stuff - adding 'clean' which is kernel state to the _user_
> _exported_ VFP hardware structure is a bad idea. So this needlessly
> causes a variation in the kernels userspace API. Please find somewhere
> else to keep kernel internal state. (As that patch comes from Catalin,
> then that comment is directed to Catalin.)
>
> In "mtd/maps: uclinux: fix sparse warnings and coding style":
>
> -struct map_info uclinux_ram_map = {
> +static struct map_info uclinux_ram_map = {
> .name = "RAM",
> - .phys = (unsigned long)&_ebss,
> - .size = 0,
> + .phys = (resource_size_t)&_ebss,
> + .bankwidth = 4,
>
> This doesn't match the description - it's a functional change. Basic rule
> of kernel patch generation: functional changes must _never_ _ever_, not in
I stumbled about that, too, but a deeper look shows that
.bankwidth = 4,
was introduced in place of the removed
mapp->bankwidth = 4;
in uclinux_mtd_init(). I didn't check the details because it's not my
patch and I don't intend (yet) to mainline it myself. (Marc: hint hint!)
> a million years, be mixed with such patches.
>
> + *virt = (__force void *)(map->virt + from);
>
> This says "wrong" to me loudly - by the mere fact that you're using __force.
> If you're having to do that, leave the sparse warning in place. Sparse is
> _not_ a tool which must produce zero warnings for kernel code. Sparse is
> an auditing tool, and as such there are valid reasons to ignore warnings.
> This is one of them.
>
> No driver should ever use __force within its code or definitions. That
> priviledge is reserved for stuff like arch code inside IO accessors where
> it really knows that it's safe.
>
> In "ARM: new architecture for ..." I expected to find a new arch/*
> directory. What you mean is "new platform" or "new machine" not
> "new architecture". Maybe "new sub-architecture". Good to see you're
> selecting NO_IOPORT here though.
Yeah, I learned NO_IOPORT from the first post of the "new architecture"
patch :-)
> config CPU_V7M
> bool "Support ARMv7-M processors"
> - depends on MACH_REALVIEW_EB && EXPERIMENTAL
> + depends on (MACH_REALVIEW_EB && EXPERIMENTAL) || ARCH_EFM32
> select THUMB2_KERNEL
> select ARM_THUMB
> select CPU_32v7M
>
> Ok, so EFM32 may or may not have a V7M CPU. Cool. What does it have
> when it doesn't have a V7M CPU? (Please fix it, like all the other CPU
> stuff in this file, so that the prompt appears for those which _may_
> have it, but it's selected by those which must _always_ have it.)
Yeah, this was pointed out in the review of my first post, too. Didn't
come around yet to fix that.
> Your code in arch/arm/mach-efm32/include/mach/system.h won't be called
> as of this merge window - that's something you should consider fixing.
yeah, I'm aware of this change and intend to update the base when
3.3-rc1 is out.
> In your serial driver, you really need to deal with which modes you
> can't set sanely: ask Alan Cox how to do this. POSIX has a requirement
> that termios modes which can't be set should be reported back. (eg,
> if you can only do one stop bit, don't blindly ignore the request for
> two stop bits.)
Ah, I thought CSTOPB means "use 1 stop bit" but it seems to request 2.
Will fix and send out a v3.
Thanks for your time
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
From: Guennadi Liakhovetski @ 2012-01-17 10:16 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Linux Media Mailing List, Rupert Eibauer, Hans Verkuil
In-Reply-To: <201201171113.14927.hansverk@cisco.com>
Hi Hans
On Tue, 17 Jan 2012, Hans Verkuil wrote:
> On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote:
> > On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote:
> > > This is an automatic generated email to let you know that the following
> > > patch were queued at the http://git.linuxtv.org/media_tree.git tree:
> > >
> > > Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
> > > Author: Hans Verkuil <hans.verkuil@cisco.com>
> > > Date: Wed Jan 11 07:37:54 2012 -0300
> >
> > [snip]
> >
> > > diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> > > b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index
> > > fd45f1c..4533068 100644
> > > --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> > > +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> > > @@ -61,8 +61,9 @@ desired output in an integer and call the
> > >
> > > <constant>VIDIOC_S_OUTPUT</constant> ioctl with a pointer to this
> > > integer. Side effects are possible. For example outputs may support
> > > different video standards, so the driver may implicitly switch the
> > > current
> > >
> > > -standard. It is good practice to select an output before querying or
> > > -negotiating any other parameters.</para>
> > > +standard.
> > > +standard. Because of these possible side effects applications
> > > +must select an output before querying or negotiating any other
> > > parameters.</para>
> >
> > something seems to be wrong here.
>
> Hi Guennadi!
>
> What's wrong here? I've no idea what you mean.
> > > +standard.
> > > +standard. Because of these possible side effects applications
doesn't seem to make much sense?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* VGA Passthru HW upgrade
From: Pavel Mateja @ 2012-01-17 10:15 UTC (permalink / raw)
To: xen-devel
Hi,
I've upgraded my XEN system with Windows 7 virtual hosts to:
MB: ASUS Crosshair V Formula (BIOS 1102)
CPU: AMD FX-8150
which is basically working bus seems to be less stable than old system.
I tried to upgrade BIOS on Formula IV but linux failed to boot the FX even on
baremetal.
I can't hear sound in DomU. Hmm, to be honest I've heard some broken pieces,..
I tried to pass AMD HD7970 but the VGA BIOS init has probably been changed and
virtual machine won't start.
And there is one more stange thing (even on old system):
lspci in Dom0 and GPU-Z in virtual machine reports only 2,5GT/s (PCI-E 1.1) on
PCI-E for VGA while the same kernel on baremetal reports 5GT/s (PCI-E 2.0).
--
Pavel Mateja
^ permalink raw reply
* Re: [PATCH 4/4] Allow unprivileged chroot when safe
From: Jamie Lokier @ 2012-01-17 10:14 UTC (permalink / raw)
To: Colin Walters
Cc: Andy Lutomirski, Casey Schaufler, Linus Torvalds, Will Drewry,
linux-kernel, keescook, john.johansen, serge.hallyn, coreyb,
pmoore, eparis, djm, segoon, rostedt, jmorris, scarybeasts, avi,
penberg, viro, mingo, akpm, khilman, borislav.petkov, amwang,
oleg, ak, eric.dumazet, gregkh, dhowells, daniel.lezcano,
linux-fsdevel, linux-security-module, olofj, mhalcrow, dlaor,
corbet, alan
In-Reply-To: <1326741967.3467.8.camel@lenny>
Colin Walters wrote:
> On Sun, 2012-01-15 at 16:37 -0800, Andy Lutomirski wrote:
>
> > Because chroot is an easy way to break out of chroot jail, CAP_SYS_ADMIN
> > is still required if the caller is already chrooted.
>
> This part is pretty gross. It means it won't work for stuff like
> containers (systemd-nspawn etc.) and furthermore
> I have plans that involve running OS trees inside a chroot, and this
> would obviously not work for that.
Indeed, I do run many of my machines inside a chroot.
The real filesystem has:
/distro/that
/distro/newer
/distro/this
instead of partitions. I'm chroot'd and fully booted up in
/distro/this, although I can see files in the others and I might run a
few things from them as well.
This isn't "userland chroot", it's the top level of the process tree:
/distro/this/sbin/init. It would be a shame if it behaved differently
just because "it's a chroot".
-- Jamie
^ permalink raw reply
* Re: [PATCH] [RFC] drm/i915: read-read semaphore optimization
From: Daniel Vetter @ 2012-01-17 10:15 UTC (permalink / raw)
To: Ben Widawsky; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <4F14A2C7.7020006@bwidawsk.net>
On Mon, Jan 16, 2012 at 02:20:55PM -0800, Ben Widawsky wrote:
> On 01/16/2012 01:50 PM, Daniel Vetter wrote:
> > On Tue, Dec 13, 2011 at 10:36:15AM -0800, Ben Widawsky wrote:
> >> On 12/13/2011 09:22 AM, Eric Anholt wrote:
> >>> On Mon, 12 Dec 2011 19:52:08 -0800, Ben Widawsky<ben@bwidawsk.net> wrote:
> >>>> Since we don't differentiate on the different GPU read domains, it
> >>>> should be safe to allow back to back reads to occur without issuing a
> >>>> wait (or flush in the non-semaphore case).
> >>>>
> >>>> This has the unfortunate side effect that we need to keep track of all
> >>>> the outstanding buffer reads so that we can synchronize on a write, to
> >>>> another ring (since we don't know which read finishes first). In other
> >>>> words, the code is quite simple for two rings, but gets more tricky for
> >>>>> 2 rings.
> >>>>
> >>>> Here is a picture of the solution to the above problem
> >>>>
> >>>> Ring 0 Ring 1 Ring 2
> >>>> batch 0 batch 1 batch 2
> >>>> read buffer A read buffer A wait batch 0
> >>>> wait batch 1
> >>>> write buffer A
> >>>>
> >>>> This code is really untested. I'm hoping for some feedback if this is
> >>>> worth cleaning up, and testing more thoroughly.
> >>>
> >>> You say it's an optimization -- do you have performance numbers?
> >>
> >> 33% improvement on a hacked version of gem_ring_sync_loop with.
> >>
> >> It's not really a valid test as it's not coherent, but this is
> >> approximately the best case improvement.
> >>
> >> Oddly semaphores doesn't make much difference in this test, which
> >> was surprising.
> >
> > Our domain tracking is already complicated in unfunny ways. And (at least
> > without a use-case showing gains with hard numbers in either perf or power
> > usage) I think this patch is the kind of "this looks cool" stuff that
> > added a lot to the current problem.
> >
> > So before adding more complexity on top I'd like to remove some of the
> > superflous stuff we already have. I.e. all the flushing_list stuff and
> > maybe other things ...
>
> Can you be more clear on what exactly you want done before taking a
> patch like this? Maybe I can work on it during some down time.
I was thinking about Eric's no-more-domains stuff specifically, which has
tons of natural split-points - and we want to exploit these for merging.
Imo step 1 would be to just rework the batch dispatch in
intel_ringbuffer.c so that we unconditionally invalidate before and flush
afterwards. The ring->flush would become a no-op. No changes to the core
flushing_list tracking for step 1.
If we can get this in for 3.4 we could (in the -next merge cycle) walk all
the callchains from their ends and rip out everything which is a no-op,
starting from ring->flush. I think that's the safest way to attack this.
Eric?
Cheers, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [PATCH] intel, gma500, lvds: Fix use after free and mem leak in psb_intel_lvds_init()
From: Patrik Jakobsson @ 2012-01-17 10:15 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linux-kernel, dri-devel, Alan Cox
In-Reply-To: <alpine.LNX.2.00.1201142211370.11547@swampdragon.chaosbits.net>
On Sat, Jan 14, 2012 at 10:15 PM, Jesper Juhl wrote:
> In psb_intel_lvds_init(), if we fail to allocate memory for
> 'psb_intel_connector' we free the memory we previously allocated for
> 'psb_intel_encoder', but we then proceed to use that free'd pointer
> when we do 'psb_intel_encoder->dev_priv = lvds_priv;'.
>
> We may also leak the memory we allocated for 'psb_intel_encoder' if we
> 'goto failed_connector;' and the variable goes out of scope.
>
> While I was there anyway, I also removed the pointless 'if
> (psb_intel_connector)' before freeing it at the 'failed_connector:'
> label - kfree() deals gracefully with NULL pointers, so it is not
> needed.
My bad, thanks for fixing
^ permalink raw reply
* [PATCH obexd] client: fix parsing of apparam on pbap driver
From: Luiz Augusto von Dentz @ 2012-01-17 10:15 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Both hdr and size need to be updated otherwise no parameters will be
parsed.
---
client/pbap.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/client/pbap.c b/client/pbap.c
index 9e9eb05..84465ac 100644
--- a/client/pbap.c
+++ b/client/pbap.c
@@ -364,8 +364,8 @@ static void read_return_apparam(struct obc_session *session,
{
struct obc_transfer *transfer = obc_session_get_transfer(session);
struct obc_transfer_params params;
- unsigned char *buf;
- size_t size = 0;
+ struct apparam_hdr *hdr;
+ size_t size;
*phone_book_size = 0;
*new_missed_calls = 0;
@@ -376,9 +376,10 @@ static void read_return_apparam(struct obc_session *session,
if (params.size < APPARAM_HDR_SIZE)
return;
- while (size > APPARAM_HDR_SIZE) {
- struct apparam_hdr *hdr = (struct apparam_hdr *) params.data;
+ hdr = (struct apparam_hdr *) params.data;
+ size = params.size;
+ while (size > APPARAM_HDR_SIZE) {
if (hdr->len > size - APPARAM_HDR_SIZE) {
error("Unexpected PBAP pullphonebook app"
" length, tag %d, len %d",
@@ -404,7 +405,7 @@ static void read_return_apparam(struct obc_session *session,
hdr->tag, hdr->len);
}
- buf += APPARAM_HDR_SIZE + hdr->len;
+ hdr += APPARAM_HDR_SIZE + hdr->len;
size -= APPARAM_HDR_SIZE + hdr->len;
}
}
--
1.7.7.5
^ permalink raw reply related
* Re: [PATCH 4/4] Allow unprivileged chroot when safe
From: Jamie Lokier @ 2012-01-17 10:14 UTC (permalink / raw)
To: Colin Walters
Cc: Andy Lutomirski, Casey Schaufler, Linus Torvalds, Will Drewry,
linux-kernel, keescook, john.johansen, serge.hallyn, coreyb,
pmoore, eparis, djm, segoon, rostedt, jmorris, scarybeasts, avi,
penberg, viro, mingo, akpm, khilman, borislav.petkov, amwang,
oleg, ak, eric.dumazet, gregkh, dhowells, daniel.lezcano,
linux-fsdevel, linux-security-module, olofj, mhalcrow, dlaor,
corbet, alan
In-Reply-To: <1326741967.3467.8.camel@lenny>
Colin Walters wrote:
> On Sun, 2012-01-15 at 16:37 -0800, Andy Lutomirski wrote:
>
> > Because chroot is an easy way to break out of chroot jail, CAP_SYS_ADMIN
> > is still required if the caller is already chrooted.
>
> This part is pretty gross. It means it won't work for stuff like
> containers (systemd-nspawn etc.) and furthermore
> I have plans that involve running OS trees inside a chroot, and this
> would obviously not work for that.
Indeed, I do run many of my machines inside a chroot.
The real filesystem has:
/distro/that
/distro/newer
/distro/this
instead of partitions. I'm chroot'd and fully booted up in
/distro/this, although I can see files in the others and I might run a
few things from them as well.
This isn't "userland chroot", it's the top level of the process tree:
/distro/this/sbin/init. It would be a shame if it behaved differently
just because "it's a chroot".
-- Jamie
^ permalink raw reply
* Re: [PATCH] mount: avoid canonicalizing pseudofs paths
From: Karel Zak @ 2012-01-17 10:14 UTC (permalink / raw)
To: Dave Reisner; +Cc: util-linux, Dave Reisner
In-Reply-To: <1326763075-11690-1-git-send-email-dreisner@archlinux.org>
On Mon, Jan 16, 2012 at 08:17:55PM -0500, Dave Reisner wrote:
> This fixes a display bug in the new mount wherein a psuedofs existing in
> $PWD by name will be resolved and shown as a real mount point.
Cool, we really need to test the code.
> $ cd /tmp; mkdir nfsd; mount | grep nfsd
> /tmp/nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
>
> Signed-off-by: Dave Reisner <dreisner@archlinux.org>
> ---
> sys-utils/mount.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
Applied, thanks.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: About the thin provision function @ kernel 3.2 or later.
From: Joe Thornber @ 2012-01-17 10:13 UTC (permalink / raw)
To: device-mapper development
In-Reply-To: <20120116155959.GC4667@thunk.org>
Hi Ted,
Thanks for taking time to look at thinp.
On Mon, Jan 16, 2012 at 10:59:59AM -0500, Ted Ts'o wrote:
> Thanks for making a pointer to the paper available! I have a question
> about one of the slides, where you say: "snapshots of external
> origins". Am I correct in suppose this means you can take a snapshot
> of something which is currently not a thin-provisioned volume?
...
> Is this a feature which is yet to be implemented? And if so, what's
> the timeline for implementing it.
Yes, that's exactly it. I do want to support it in the near future
(2-3 months). There are a few options on this front.
i) We only support a read-only external origin. Of course people can
use snapshots if they want writeable versions of the current state.
An explicit merge facility will need to be added if people want to
copy the snap back over the origin. This is by far the simplest
approach, and I'll probably start with this - at least in a dev branch.
ii) We support read/write origins. When I last looked at this 15
months ago I struggled to come up with a metadata design that allowed
both efficient snapshot lookup _and_ efficient snapshot deletion. I'm
expecting people to use many, many more snapshots with thinp; deletion
performance really is a problem.
iii) We add support to patch metadata changes into the running
metadata device. This would allow us to map the origin directly into
the pools data device (eg, using a linear target). And then introduce
a mapping for that origin. This would mean the origin would appear as
a thin dev within the pool. This approach greatly improves the
performance since we wouldn't have to always COW on the first write to
an origin block (i.e. the overlapping block optimisation is still
valid).
> If this is not a feature to be implemented, can I please put it on the
> wishlist? I can imagine a lot of ext4 users who would be interested
> in thin-provisioning, especially if there is discard support such than
> when we delete a file, we send a discard which causes the
> thin-provisioned space in the snapshot to be dropped. (This is also
> apparently not implemented, from what I can tell from the source; do
> you have an approximate idea of where in the priority list / when it
> is scheduled to be implemented?)
Discard was in until recently. There were some race conditions
associated with it that I didn't have time to work through before the
merge window. Expect this to reappear sometime in the next 2-3 months.
- Joe
^ permalink raw reply
* Re: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
From: Hans Verkuil @ 2012-01-17 10:13 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-media, linuxtv-commits, Rupert Eibauer, Hans Verkuil
In-Reply-To: <Pine.LNX.4.64.1201162315200.15379@axis700.grange>
On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote:
> On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote:
> > This is an automatic generated email to let you know that the following
> > patch were queued at the http://git.linuxtv.org/media_tree.git tree:
> >
> > Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
> > Author: Hans Verkuil <hans.verkuil@cisco.com>
> > Date: Wed Jan 11 07:37:54 2012 -0300
>
> [snip]
>
> > diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> > b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index
> > fd45f1c..4533068 100644
> > --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> > +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml
> > @@ -61,8 +61,9 @@ desired output in an integer and call the
> >
> > <constant>VIDIOC_S_OUTPUT</constant> ioctl with a pointer to this
> > integer. Side effects are possible. For example outputs may support
> > different video standards, so the driver may implicitly switch the
> > current
> >
> > -standard. It is good practice to select an output before querying or
> > -negotiating any other parameters.</para>
> > +standard.
> > +standard. Because of these possible side effects applications
> > +must select an output before querying or negotiating any other
> > parameters.</para>
>
> something seems to be wrong here.
Hi Guennadi!
What's wrong here? I've no idea what you mean.
Regards,
Hans
^ permalink raw reply
* [GIT PULL] sound fix for 3.3-rc1
From: Takashi Iwai @ 2012-01-17 10:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Linus,
please pull sound fixes for v3.3-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
The topmost commit is f0e48b6bd4e407459715240cd241ddb6b89bdf81
All small fixes below after the first merge.
Thanks!
Takashi
===
Clemens Ladisch (1):
ALSA: virtuoso: Xonar DS: fix polarity of front output
David Henningsson (2):
ALSA: HDA: Use LPIB position fix for Macbook Pro 7,1
ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
Raymond Yau (2):
ALSA: Au88x0 - Support 4 channels playback when AC97 codecs has SDAC bit
ALSA: Au88x0 - Reduce the number of playback subdevices of au8830 from 32 to 16
Takashi Iwai (1):
ALSA: Don't prompt for CONFIG_SND_COMPRESS_OFFLOAD
---
sound/core/Kconfig | 13 +++----------
sound/pci/au88x0/au88x0.c | 13 +++++++------
sound/pci/au88x0/au88x0.h | 1 +
sound/pci/au88x0/au88x0_pcm.c | 1 +
sound/pci/hda/hda_intel.c | 1 +
sound/pci/hda/patch_sigmatel.c | 2 +-
sound/pci/oxygen/xonar_wm87x6.c | 1 +
7 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/sound/core/Kconfig b/sound/core/Kconfig
index ad40938..b413ed0 100644
--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -12,6 +12,9 @@ config SND_HWDEP
config SND_RAWMIDI
tristate
+config SND_COMPRESS_OFFLOAD
+ tristate
+
# To be effective this also requires INPUT - users should say:
# select SND_JACK if INPUT=y || INPUT=SND
# to avoid having to force INPUT on.
@@ -154,16 +157,6 @@ config SND_DYNAMIC_MINORS
If you are unsure about this, say N here.
-config SND_COMPRESS_OFFLOAD
- tristate "ALSA Compressed audio offload support"
- default n
- help
- If you want support for offloading compressed audio and have such
- a hardware, then you should say Y here and also to the DSP driver
- of your platform.
-
- If you are unsure about this, say N here.
-
config SND_SUPPORT_OLD_API
bool "Support old ALSA API"
default y
diff --git a/sound/pci/au88x0/au88x0.c b/sound/pci/au88x0/au88x0.c
index 762bb10..f13ad53 100644
--- a/sound/pci/au88x0/au88x0.c
+++ b/sound/pci/au88x0/au88x0.c
@@ -268,8 +268,14 @@ snd_vortex_probe(struct pci_dev *pci, const struct pci_device_id *pci_id)
card->shortname, chip->io, chip->irq);
// (4) Alloc components.
+ err = snd_vortex_mixer(chip);
+ if (err < 0) {
+ snd_card_free(card);
+ return err;
+ }
// ADB pcm.
- if ((err = snd_vortex_new_pcm(chip, VORTEX_PCM_ADB, NR_ADB)) < 0) {
+ err = snd_vortex_new_pcm(chip, VORTEX_PCM_ADB, NR_PCM);
+ if (err < 0) {
snd_card_free(card);
return err;
}
@@ -299,11 +305,6 @@ snd_vortex_probe(struct pci_dev *pci, const struct pci_device_id *pci_id)
return err;
}
#endif
- // snd_ac97_mixer and Vortex mixer.
- if ((err = snd_vortex_mixer(chip)) < 0) {
- snd_card_free(card);
- return err;
- }
if ((err = snd_vortex_midi(chip)) < 0) {
snd_card_free(card);
return err;
diff --git a/sound/pci/au88x0/au88x0.h b/sound/pci/au88x0/au88x0.h
index 02f6e08..bb93815 100644
--- a/sound/pci/au88x0/au88x0.h
+++ b/sound/pci/au88x0/au88x0.h
@@ -105,6 +105,7 @@
#define MIX_SPDIF(x) (vortex->mixspdif[x])
#define NR_WTPB 0x20 /* WT channels per each bank. */
+#define NR_PCM 0x10
/* Structs */
typedef struct {
diff --git a/sound/pci/au88x0/au88x0_pcm.c b/sound/pci/au88x0/au88x0_pcm.c
index 0488633..0ef2f97 100644
--- a/sound/pci/au88x0/au88x0_pcm.c
+++ b/sound/pci/au88x0/au88x0_pcm.c
@@ -168,6 +168,7 @@ static int snd_vortex_pcm_open(struct snd_pcm_substream *substream)
runtime->hw = snd_vortex_playback_hw_adb;
#ifdef CHIP_AU8830
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
+ VORTEX_IS_QUAD(vortex) &&
VORTEX_PCM_TYPE(substream->pcm) == VORTEX_PCM_ADB) {
runtime->hw.channels_max = 4;
snd_pcm_hw_constraint_list(runtime, 0,
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 0852e20..fb35474 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2498,6 +2498,7 @@ static struct snd_pci_quirk position_fix_list[] __devinitdata = {
SND_PCI_QUIRK(0x1043, 0x81b3, "ASUS", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS M2V", POS_FIX_LPIB),
SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x10de, 0xcb89, "Macbook Pro 7,1", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1297, 0x3166, "Shuttle", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1458, 0xa022, "ga-ma770-ud3", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1462, 0x1002, "MSI Wind U115", POS_FIX_LPIB),
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 87e684f..3556408 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -1596,7 +1596,7 @@ static const struct snd_pci_quirk stac92hd73xx_cfg_tbl[] = {
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02bd,
"Dell Studio 1557", STAC_DELL_M6_DMIC),
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02fe,
- "Dell Studio XPS 1645", STAC_DELL_M6_BOTH),
+ "Dell Studio XPS 1645", STAC_DELL_M6_DMIC),
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0413,
"Dell Studio 1558", STAC_DELL_M6_DMIC),
{} /* terminator */
diff --git a/sound/pci/oxygen/xonar_wm87x6.c b/sound/pci/oxygen/xonar_wm87x6.c
index 478303e..63cff90 100644
--- a/sound/pci/oxygen/xonar_wm87x6.c
+++ b/sound/pci/oxygen/xonar_wm87x6.c
@@ -177,6 +177,7 @@ static void wm8776_registers_init(struct oxygen *chip)
struct xonar_wm87x6 *data = chip->model_data;
wm8776_write(chip, WM8776_RESET, 0);
+ wm8776_write(chip, WM8776_PHASESWAP, WM8776_PH_MASK);
wm8776_write(chip, WM8776_DACCTRL1, WM8776_DZCEN |
WM8776_PL_LEFT_LEFT | WM8776_PL_RIGHT_RIGHT);
wm8776_write(chip, WM8776_DACMUTE, chip->dac_mute ? WM8776_DMUTE : 0);
^ permalink raw reply related
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.