All of lore.kernel.org
 help / color / mirror / Atom feed
* Question about: linux-linaro-2.6.38.7 booting the ubuntu 10.10 filesystem
From: Russell King - ARM Linux @ 2011-10-22 13:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CALQsFO+AbEH-LtEYCY7wDZW=7U=wYZrQcMPeoDio_BdkByWTcw@mail.gmail.com>

On Sat, Oct 22, 2011 at 05:35:52PM +0800, David Yang wrote:
>  I found in my timer driver,I didn't implement the "init_sched_clock"
> function.

Have you selected HAVE_SCHED_CLOCK ?

^ permalink raw reply

* Re: Build Failure - signgp
From: Russell Morris @ 2011-10-22 13:35 UTC (permalink / raw)
  To: openembedded-devel
In-Reply-To: <CAMKF1sqUsuZ5_rmcsq5o1FsYw42mz9VVC=QXxY13FkMxqA6jaA@mail.gmail.com>

Hi,
This worked - thanks!!!
I have one last question though ... :-). This is two patches that I have applied (that both work, great news there) - but why are they not applied to the git repository? Just curious, that's all.
Thanks again,... Russell


On Fri, 10/21/2011 11:49 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Fri, Oct 21, 2011 at 8:20 AM, Russell Morris
> <openembedded@rkmorris.us> wrote:
> > Hi,
> >
> > I am trying to build console-image for an am3517-evm (machine), but x-load fails due to issues with signgp. Has anyone else been able to build this successfully?
> >
> 
> Please apply this patch
> http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2011-October/005232.html
> 
> > Thanks!
> >
> > ... Russell
> >
> >
> > PS: Here is the failure log,
> >
> > OE Build Configuration:
> > BB_VERSION        = "1.13.3"
> > TARGET_ARCH       = "arm"
> > TARGET_OS         = "linux-gnueabi"
> > MACHINE           = "am3517-evm"
> > DISTRO            = "angstrom"
> > DISTRO_VERSION    = "v2011.10-core"
> > TUNE_FEATURES     = "armv7a vfp neon cortexa8"
> > TARGET_FPU        = "vfp-neon"
> > meta-angstrom     = "master:3dc02ecc7ee7d9e03b03025ddf4436f9ee8029fb"
> > meta-oe
> > meta-efl
> > meta-gpe
> > meta-gnome
> > meta-xfce         = "master:0368dfd5d8285fe31c853097846e8a6822c7cda0"
> > meta-ti           = "master:fa296c64e42de57ac8df8fb7b9c30e393ed71ce9"
> > meta-ettus        = "master:617506b5cfd2b8325d85f0dcba0232c3f796d044"
> > meta-efikamx      = "master:2ef47fdd4e8232d766c0c63d9427253ee56e31d0"
> > meta-nslu2        = "master:9080394ae0a040dd7b05ac49f9480e4d71631b55"
> > meta-htc
> > meta-nokia
> > meta-openmoko
> > meta-palm         = "master:fbd6e9e8517e7ec58ad36474bd7fa01275e159f1"
> > meta-sugarbay
> > meta-crownbay
> > meta-emenlow
> > meta-fishriver
> > meta-jasperforest
> > meta-n450         = "master:42fcbb128c5fe812068bb86934ab31ac92fd9f83"
> > meta              = "master:99da9a4e65f9dffb04efc3ad60125194c476d6b3"
> >
> > NOTE: Resolving any missing task queue dependencies
> > NOTE: Preparing runqueue
> > NOTE: Executing SetScene Tasks
> > NOTE: Executing RunQueue Tasks
> > NOTE: Running task 944 of 957 (ID: 4, /mnt/oe/setup-scripts/sources/meta-ti/recipes-bsp/x-load/signgp.bb, do_fetch)
> > NOTE: package signgp-1.0-r0: task do_fetch: Started
> > NOTE: package signgp-1.0-r0: task do_fetch: Succeeded
> > NOTE: Running task 945 of 957 (ID: 0, /mnt/oe/setup-scripts/sources/meta-ti/recipes-bsp/x-load/signgp.bb, do_unpack)
> > NOTE: package signgp-1.0-r0: task do_unpack: Started
> > NOTE: package signgp-1.0-r0: task do_unpack: Succeeded
> > NOTE: Running task 946 of 957 (ID: 1, /mnt/oe/setup-scripts/sources/meta-ti/recipes-bsp/x-load/signgp.bb, do_patch)
> > NOTE: package signgp-1.0-r0: task do_patch: Started
> > NOTE: package signgp-1.0-r0: task do_patch: Succeeded
> > NOTE: Running task 947 of 957 (ID: 6, /mnt/oe/setup-scripts/sources/meta-ti/recipes-bsp/x-load/signgp.bb, do_configure)
> > NOTE: Running task 948 of 957 (ID: 12, /mnt/oe/setup-scripts/sources/meta-ti/recipes-bsp/x-load/signgp.bb, do_populate_lic)
> > NOTE: package signgp-1.0-r0: task do_configure: Started
> > ERROR: Function 'signgp: LIC_FILES_CHKSUM points to an invalid file: /mnt/oe/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/signgp-1.0-r0/signgp-1.0/signGP.c' failed
> > ERROR: Logfile of failure stored in: /mnt/oe/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/signgp-1.0-r0/temp/log.do_configure.28702
> > Log data follows:
> > | + cd /mnt/oe/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/signgp-1.0-r0/signgp-1.0
> > | + do_configure
> > | + base_do_configure
> > | + :
> > | NOTE: Checking autotools environment for common misconfiguration
> > | ERROR: Function 'signgp: LIC_FILES_CHKSUM points to an invalid file: /mnt/oe/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/signgp-1.0-r0/signgp-1.0/signGP.c' failed
> > NOTE: package signgp-1.0-r0: task do_configure: Failed
> > NOTE: package signgp-1.0-r0: task do_populate_lic: Started
> > ERROR: Task 6 (/mnt/oe/setup-scripts/sources/meta-ti/recipes-bsp/x-load/signgp.bb, do_configure) failed with exit code '1'
> > Waiting for 1 active tasks to finish:
> > 0: signgp-1.0-r0 do_populate_lic (pid 28703)
> > WARNING: /mnt/oe/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/signgp-1.0-r0/signgp-1.0/signGP.c could not be copied for some reason. It may not exist. WARN for now.
> > WARNING: signgp: No generic license file exists for: NewBSD at /mnt/oe/setup-scripts/sources/openembedded-core/meta/files/common-licenses
> > WARNING: signgp: There is also no SPDXLICENSEMAP for this license type: NewBSD at /mnt/oe/setup-scripts/sources/openembedded-core/meta/files/common-licenses
> > NOTE: package signgp-1.0-r0: task do_populate_lic: Succeeded
> > ERROR: '/mnt/oe/setup-scripts/sources/meta-ti/recipes-bsp/x-load/signgp.bb' failed
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From raj.khem@gmail.com Sat Oct 22 16:24:18 2011
Received: from mail-yx0-f175.google.com ([209.85.213.175])
	by linuxtogo.org with esmtp (Exim 4.72)
	(envelope-from <raj.khem@gmail.com>) id 1RHcUk-0004cj-Kl
	for openembedded-devel@lists.openembedded.org;
	Sat, 22 Oct 2011 16:24:18 +0200
Received: by yxi13 with SMTP id 13so218921yxi.6
	for <openembedded-devel@lists.openembedded.org>;
	Sat, 22 Oct 2011 07:18:22 -0700 (PDT)
DKIM-Signature: v

^ permalink raw reply

* Re: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
From: Russell King - ARM Linux @ 2011-10-22 13:47 UTC (permalink / raw)
  To: Paul Schilling
  Cc: Nicolas Pitre, Kukjin Kim, linux-serial, Boojin Kim,
	Greg Kroah-Hartman, linux-kernel, Ben Dooks, linux-arm-kernel,
	Alan Cox
In-Reply-To: <1319255194-4799-1-git-send-email-paul.s.schilling@gmail.com>

On Fri, Oct 21, 2011 at 10:46:34PM -0500, Paul Schilling wrote:
> +config SAMSUNG_HAS_RS485
> +	bool "Enable RS485 support for Samsung"
> +	depends on SERIAL_SAMSUNG && (MACH_CONDOR2440 || MACH_CONDOR2416 || MACH_MINI2440)
> +	default y if (MACH_CONDOR2440 || MACH_CONDOR2416)
> +	default n if (MACH_MINI2440)
> +
> +config SAMSUNG_485_LOW_RES_TIMER
> +    bool "Samsung RS-485 use low res timer during transmit"
> +    depends on SERIAL_SAMSUNG && SAMSUNG_HAS_RS485
> +    default n

n is the default, so this doesn't need to be specified.

> +static void s3c24xx_serial_rx_fifo_enable(
> +		struct uart_port *port,
> +		unsigned int en)
> +{
> +	unsigned long flags;
> +	unsigned int ucon;
> +	static unsigned int last_state = 1;
> +/* FIXME */
> +	#if 0
> +	if (last_state != en) {
> +
> +		struct s3c2410_uartcfg *cfg = s3c24xx_port_to_cfg(port);
> +
> +		spin_lock_irqsave(&port->lock, flags);
> +
> +		ucon = rd_regl(port, S3C2410_UCON);
> +
> +		ucon &= ~(S3C2440_UFCON_RXTRIG32 | S3C2410_UCON_RXILEVEL);
> +
> +		if (en) {
> +			ucon |= cfg->ucon;
> +		}
> +
> +		wr_regl(port, S3C2410_UCON, ucon);
> +
> +		spin_unlock_irqrestore(&port->lock, flags);
> +	}
> +#endif

This looks like dead code.

> +		} else {
> +			/* Set a short timer to toggle RTS */
> +			mod_timer(
> +					&(ourport->rs485_tx_timer),
> +					jiffies + usecs_to_jiffies(
> +							ourport->char_time_usec
> +							/ 10));

This could do with being better formatted.  Also, & doesn't need following
parens.

> +	/* Read UART transmit status register */
> +	utrstat = rd_regl(&(ourport->port), S3C2410_UTRSTAT);

Doesn't need the parens.

> +/* Callback array*/
> +enum hrtimer_restart (*callback_list[CONFIG_SERIAL_SAMSUNG_UARTS])(struct hrtimer *) = {
> +		&rs485_hr_timer_callback_uart0,
> +		&rs485_hr_timer_callback_uart1,
> +
> +#if CONFIG_SERIAL_SAMSUNG_UARTS > 2
> +		&rs485_hr_timer_callback_uart2,
> +#endif
> +
> +#if CONFIG_SERIAL_SAMSUNG_UARTS > 3
> +		&rs485_hr_timer_callback_uart3,
> +#endif

Silly indentation - this doesn't need two tabs.

> +};
> +
> +#endif
> +#endif /* CONFIG_SAMSUNG_HAS_RS485 */
> +
> +
>  static void s3c24xx_serial_stop_tx(struct uart_port *port)
>  {
>  	struct s3c24xx_uart_port *ourport = to_ourport(port);
>  
>  	if (tx_enabled(port)) {
> +#ifdef CONFIG_SAMSUNG_HAS_RS485
> +		if (ourport->rs485.flags & SER_RS485_ENABLED) {
> +#ifdef CONFIG_SAMSUNG_485_LOW_RES_TIMER
> +			/* Set a short timer to toggle RTS */
> +			mod_timer(&(ourport->rs485_tx_timer),

Doesn't need parens.

> +					jiffies + usecs_to_jiffies(ourport->char_time_usec * s3c24xx_serial_tx_getfifocnt(ourport)));
> +#else
> +			ktime_t kt;
> +
> +			/* Set time struct to one char time. */
> +			kt = ktime_set(0, ourport->char_time_nanosec);
> +
> +			/* Start the high res timer. */
> +			hrtimer_start(&(ourport->hr_rs485_tx_timer), kt, HRTIMER_MODE_REL);

Doesn't need parens.

> +#endif /* CONFIG_SAMSUNG_485_LOW_RES_TIMER */
> +
> +			s3c24xx_serial_rx_fifo_enable(port, 0);
> +
> +		}
> +#endif /* CONFIG_SAMSUNG_HAS_RS485 */
> +
>  		disable_irq_nosync(ourport->tx_irq);
>  		tx_enabled(port) = 0;
> -		if (port->flags & UPF_CONS_FLOW)
> +		if (port->flags & UPF_CONS_FLOW) {
>  			s3c24xx_serial_rx_enable(port);
> +		}

Why are you reformatting code?

> @@ -785,7 +1177,7 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
>  	port->ignore_status_mask = 0;
>  	if (termios->c_iflag & IGNPAR)
>  		port->ignore_status_mask |= S3C2410_UERSTAT_OVERRUN;
> -	if (termios->c_iflag & IGNBRK && termios->c_iflag & IGNPAR)
> +	if ((termios->c_iflag & IGNBRK) && (termios->c_iflag & IGNPAR))

More code reformatting.

> @@ -830,7 +1228,7 @@ static void s3c24xx_serial_config_port(struct uart_port *port, int flags)
>  {
>  	struct s3c24xx_uart_info *info = s3c24xx_port_to_info(port);
>  
> -	if (flags & UART_CONFIG_TYPE &&
> +	if ((flags & UART_CONFIG_TYPE) &&

And some more.

> +#if 0
> +	dev_info(port., "rts: on send = %i, after = %i, enabled = %i",

That can't be correct - and as its #if 0'd out, either remove this or
fix it to be correct (and use dev_dbg if you want it to be debugging.)

> +static ssize_t s3c24xx_serial_set_485_mode(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buf, size_t count)
> +
> +{
> +	struct uart_port *port = s3c24xx_dev_to_port(dev);
> +	struct s3c24xx_uart_port *ourport = to_ourport(port);
> +
> +	if (!strncmp(buf, "Enabled", 7)) {
> +		ourport->rs485.flags |= SER_RS485_ENABLED;
> +	} else if (!strncmp(buf, "Disabled", 8)) {

Do you really require the first character to be capitalized?

> +#ifdef CONFIG_SAMSUNG_HAS_RS485
> +
> +	ret = device_create_file(&dev->dev, &dev_attr_485_status);
> +	if (ret < 0)
> +		printk(KERN_ERR "%s: failed to add 485 status attr.\n", __func__);

pr_err() ?  dev_err() ?

^ permalink raw reply

* [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
From: Russell King - ARM Linux @ 2011-10-22 13:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319255194-4799-1-git-send-email-paul.s.schilling@gmail.com>

On Fri, Oct 21, 2011 at 10:46:34PM -0500, Paul Schilling wrote:
> +config SAMSUNG_HAS_RS485
> +	bool "Enable RS485 support for Samsung"
> +	depends on SERIAL_SAMSUNG && (MACH_CONDOR2440 || MACH_CONDOR2416 || MACH_MINI2440)
> +	default y if (MACH_CONDOR2440 || MACH_CONDOR2416)
> +	default n if (MACH_MINI2440)
> +
> +config SAMSUNG_485_LOW_RES_TIMER
> +    bool "Samsung RS-485 use low res timer during transmit"
> +    depends on SERIAL_SAMSUNG && SAMSUNG_HAS_RS485
> +    default n

n is the default, so this doesn't need to be specified.

> +static void s3c24xx_serial_rx_fifo_enable(
> +		struct uart_port *port,
> +		unsigned int en)
> +{
> +	unsigned long flags;
> +	unsigned int ucon;
> +	static unsigned int last_state = 1;
> +/* FIXME */
> +	#if 0
> +	if (last_state != en) {
> +
> +		struct s3c2410_uartcfg *cfg = s3c24xx_port_to_cfg(port);
> +
> +		spin_lock_irqsave(&port->lock, flags);
> +
> +		ucon = rd_regl(port, S3C2410_UCON);
> +
> +		ucon &= ~(S3C2440_UFCON_RXTRIG32 | S3C2410_UCON_RXILEVEL);
> +
> +		if (en) {
> +			ucon |= cfg->ucon;
> +		}
> +
> +		wr_regl(port, S3C2410_UCON, ucon);
> +
> +		spin_unlock_irqrestore(&port->lock, flags);
> +	}
> +#endif

This looks like dead code.

> +		} else {
> +			/* Set a short timer to toggle RTS */
> +			mod_timer(
> +					&(ourport->rs485_tx_timer),
> +					jiffies + usecs_to_jiffies(
> +							ourport->char_time_usec
> +							/ 10));

This could do with being better formatted.  Also, & doesn't need following
parens.

> +	/* Read UART transmit status register */
> +	utrstat = rd_regl(&(ourport->port), S3C2410_UTRSTAT);

Doesn't need the parens.

> +/* Callback array*/
> +enum hrtimer_restart (*callback_list[CONFIG_SERIAL_SAMSUNG_UARTS])(struct hrtimer *) = {
> +		&rs485_hr_timer_callback_uart0,
> +		&rs485_hr_timer_callback_uart1,
> +
> +#if CONFIG_SERIAL_SAMSUNG_UARTS > 2
> +		&rs485_hr_timer_callback_uart2,
> +#endif
> +
> +#if CONFIG_SERIAL_SAMSUNG_UARTS > 3
> +		&rs485_hr_timer_callback_uart3,
> +#endif

Silly indentation - this doesn't need two tabs.

> +};
> +
> +#endif
> +#endif /* CONFIG_SAMSUNG_HAS_RS485 */
> +
> +
>  static void s3c24xx_serial_stop_tx(struct uart_port *port)
>  {
>  	struct s3c24xx_uart_port *ourport = to_ourport(port);
>  
>  	if (tx_enabled(port)) {
> +#ifdef CONFIG_SAMSUNG_HAS_RS485
> +		if (ourport->rs485.flags & SER_RS485_ENABLED) {
> +#ifdef CONFIG_SAMSUNG_485_LOW_RES_TIMER
> +			/* Set a short timer to toggle RTS */
> +			mod_timer(&(ourport->rs485_tx_timer),

Doesn't need parens.

> +					jiffies + usecs_to_jiffies(ourport->char_time_usec * s3c24xx_serial_tx_getfifocnt(ourport)));
> +#else
> +			ktime_t kt;
> +
> +			/* Set time struct to one char time. */
> +			kt = ktime_set(0, ourport->char_time_nanosec);
> +
> +			/* Start the high res timer. */
> +			hrtimer_start(&(ourport->hr_rs485_tx_timer), kt, HRTIMER_MODE_REL);

Doesn't need parens.

> +#endif /* CONFIG_SAMSUNG_485_LOW_RES_TIMER */
> +
> +			s3c24xx_serial_rx_fifo_enable(port, 0);
> +
> +		}
> +#endif /* CONFIG_SAMSUNG_HAS_RS485 */
> +
>  		disable_irq_nosync(ourport->tx_irq);
>  		tx_enabled(port) = 0;
> -		if (port->flags & UPF_CONS_FLOW)
> +		if (port->flags & UPF_CONS_FLOW) {
>  			s3c24xx_serial_rx_enable(port);
> +		}

Why are you reformatting code?

> @@ -785,7 +1177,7 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
>  	port->ignore_status_mask = 0;
>  	if (termios->c_iflag & IGNPAR)
>  		port->ignore_status_mask |= S3C2410_UERSTAT_OVERRUN;
> -	if (termios->c_iflag & IGNBRK && termios->c_iflag & IGNPAR)
> +	if ((termios->c_iflag & IGNBRK) && (termios->c_iflag & IGNPAR))

More code reformatting.

> @@ -830,7 +1228,7 @@ static void s3c24xx_serial_config_port(struct uart_port *port, int flags)
>  {
>  	struct s3c24xx_uart_info *info = s3c24xx_port_to_info(port);
>  
> -	if (flags & UART_CONFIG_TYPE &&
> +	if ((flags & UART_CONFIG_TYPE) &&

And some more.

> +#if 0
> +	dev_info(port., "rts: on send = %i, after = %i, enabled = %i",

That can't be correct - and as its #if 0'd out, either remove this or
fix it to be correct (and use dev_dbg if you want it to be debugging.)

> +static ssize_t s3c24xx_serial_set_485_mode(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buf, size_t count)
> +
> +{
> +	struct uart_port *port = s3c24xx_dev_to_port(dev);
> +	struct s3c24xx_uart_port *ourport = to_ourport(port);
> +
> +	if (!strncmp(buf, "Enabled", 7)) {
> +		ourport->rs485.flags |= SER_RS485_ENABLED;
> +	} else if (!strncmp(buf, "Disabled", 8)) {

Do you really require the first character to be capitalized?

> +#ifdef CONFIG_SAMSUNG_HAS_RS485
> +
> +	ret = device_create_file(&dev->dev, &dev_attr_485_status);
> +	if (ret < 0)
> +		printk(KERN_ERR "%s: failed to add 485 status attr.\n", __func__);

pr_err() ?  dev_err() ?

^ permalink raw reply

* Re: OMAP3 ISP with digital sensor
From: Gary Thomas @ 2011-10-22 13:47 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-media@vger.kernel.org
In-Reply-To: <201110211834.52113.laurent.pinchart@ideasonboard.com>

On 2011-10-21 10:34, Laurent Pinchart wrote:
> Hi Gary,
>
> Aarrghhhh, I'm sorry for the very late reply. Your mail splipped through the
> cracks :-/
>
> (94 mails to go in my inbox, then I'll move to my mailing lists backlog :-))
>
> On Tuesday 11 October 2011 15:42:01 Gary Thomas wrote:
>> Laurent,
>>
>> Do you have an example of how to use a digital sensor, in particular
>> the MT9P031, with the OMAP3 ISP?
>
> Yes, you can find sample board code in the omap3isp-sensors-board branch of
> the git://linuxtv.org/pinchartl/media.git repository.
>

No worries, I just now got my hands on one :-)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply

* Re: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
From: Russell King - ARM Linux @ 2011-10-22 13:47 UTC (permalink / raw)
  To: Paul Schilling
  Cc: Ben Dooks, Kukjin Kim, Alan Cox, Greg Kroah-Hartman, Boojin Kim,
	Nicolas Pitre, linux-arm-kernel, linux-kernel, linux-serial
In-Reply-To: <1319255194-4799-1-git-send-email-paul.s.schilling@gmail.com>

On Fri, Oct 21, 2011 at 10:46:34PM -0500, Paul Schilling wrote:
> +config SAMSUNG_HAS_RS485
> +	bool "Enable RS485 support for Samsung"
> +	depends on SERIAL_SAMSUNG && (MACH_CONDOR2440 || MACH_CONDOR2416 || MACH_MINI2440)
> +	default y if (MACH_CONDOR2440 || MACH_CONDOR2416)
> +	default n if (MACH_MINI2440)
> +
> +config SAMSUNG_485_LOW_RES_TIMER
> +    bool "Samsung RS-485 use low res timer during transmit"
> +    depends on SERIAL_SAMSUNG && SAMSUNG_HAS_RS485
> +    default n

n is the default, so this doesn't need to be specified.

> +static void s3c24xx_serial_rx_fifo_enable(
> +		struct uart_port *port,
> +		unsigned int en)
> +{
> +	unsigned long flags;
> +	unsigned int ucon;
> +	static unsigned int last_state = 1;
> +/* FIXME */
> +	#if 0
> +	if (last_state != en) {
> +
> +		struct s3c2410_uartcfg *cfg = s3c24xx_port_to_cfg(port);
> +
> +		spin_lock_irqsave(&port->lock, flags);
> +
> +		ucon = rd_regl(port, S3C2410_UCON);
> +
> +		ucon &= ~(S3C2440_UFCON_RXTRIG32 | S3C2410_UCON_RXILEVEL);
> +
> +		if (en) {
> +			ucon |= cfg->ucon;
> +		}
> +
> +		wr_regl(port, S3C2410_UCON, ucon);
> +
> +		spin_unlock_irqrestore(&port->lock, flags);
> +	}
> +#endif

This looks like dead code.

> +		} else {
> +			/* Set a short timer to toggle RTS */
> +			mod_timer(
> +					&(ourport->rs485_tx_timer),
> +					jiffies + usecs_to_jiffies(
> +							ourport->char_time_usec
> +							/ 10));

This could do with being better formatted.  Also, & doesn't need following
parens.

> +	/* Read UART transmit status register */
> +	utrstat = rd_regl(&(ourport->port), S3C2410_UTRSTAT);

Doesn't need the parens.

> +/* Callback array*/
> +enum hrtimer_restart (*callback_list[CONFIG_SERIAL_SAMSUNG_UARTS])(struct hrtimer *) = {
> +		&rs485_hr_timer_callback_uart0,
> +		&rs485_hr_timer_callback_uart1,
> +
> +#if CONFIG_SERIAL_SAMSUNG_UARTS > 2
> +		&rs485_hr_timer_callback_uart2,
> +#endif
> +
> +#if CONFIG_SERIAL_SAMSUNG_UARTS > 3
> +		&rs485_hr_timer_callback_uart3,
> +#endif

Silly indentation - this doesn't need two tabs.

> +};
> +
> +#endif
> +#endif /* CONFIG_SAMSUNG_HAS_RS485 */
> +
> +
>  static void s3c24xx_serial_stop_tx(struct uart_port *port)
>  {
>  	struct s3c24xx_uart_port *ourport = to_ourport(port);
>  
>  	if (tx_enabled(port)) {
> +#ifdef CONFIG_SAMSUNG_HAS_RS485
> +		if (ourport->rs485.flags & SER_RS485_ENABLED) {
> +#ifdef CONFIG_SAMSUNG_485_LOW_RES_TIMER
> +			/* Set a short timer to toggle RTS */
> +			mod_timer(&(ourport->rs485_tx_timer),

Doesn't need parens.

> +					jiffies + usecs_to_jiffies(ourport->char_time_usec * s3c24xx_serial_tx_getfifocnt(ourport)));
> +#else
> +			ktime_t kt;
> +
> +			/* Set time struct to one char time. */
> +			kt = ktime_set(0, ourport->char_time_nanosec);
> +
> +			/* Start the high res timer. */
> +			hrtimer_start(&(ourport->hr_rs485_tx_timer), kt, HRTIMER_MODE_REL);

Doesn't need parens.

> +#endif /* CONFIG_SAMSUNG_485_LOW_RES_TIMER */
> +
> +			s3c24xx_serial_rx_fifo_enable(port, 0);
> +
> +		}
> +#endif /* CONFIG_SAMSUNG_HAS_RS485 */
> +
>  		disable_irq_nosync(ourport->tx_irq);
>  		tx_enabled(port) = 0;
> -		if (port->flags & UPF_CONS_FLOW)
> +		if (port->flags & UPF_CONS_FLOW) {
>  			s3c24xx_serial_rx_enable(port);
> +		}

Why are you reformatting code?

> @@ -785,7 +1177,7 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
>  	port->ignore_status_mask = 0;
>  	if (termios->c_iflag & IGNPAR)
>  		port->ignore_status_mask |= S3C2410_UERSTAT_OVERRUN;
> -	if (termios->c_iflag & IGNBRK && termios->c_iflag & IGNPAR)
> +	if ((termios->c_iflag & IGNBRK) && (termios->c_iflag & IGNPAR))

More code reformatting.

> @@ -830,7 +1228,7 @@ static void s3c24xx_serial_config_port(struct uart_port *port, int flags)
>  {
>  	struct s3c24xx_uart_info *info = s3c24xx_port_to_info(port);
>  
> -	if (flags & UART_CONFIG_TYPE &&
> +	if ((flags & UART_CONFIG_TYPE) &&

And some more.

> +#if 0
> +	dev_info(port., "rts: on send = %i, after = %i, enabled = %i",

That can't be correct - and as its #if 0'd out, either remove this or
fix it to be correct (and use dev_dbg if you want it to be debugging.)

> +static ssize_t s3c24xx_serial_set_485_mode(struct device *dev,
> +		struct device_attribute *attr,
> +		const char *buf, size_t count)
> +
> +{
> +	struct uart_port *port = s3c24xx_dev_to_port(dev);
> +	struct s3c24xx_uart_port *ourport = to_ourport(port);
> +
> +	if (!strncmp(buf, "Enabled", 7)) {
> +		ourport->rs485.flags |= SER_RS485_ENABLED;
> +	} else if (!strncmp(buf, "Disabled", 8)) {

Do you really require the first character to be capitalized?

> +#ifdef CONFIG_SAMSUNG_HAS_RS485
> +
> +	ret = device_create_file(&dev->dev, &dev_attr_485_status);
> +	if (ret < 0)
> +		printk(KERN_ERR "%s: failed to add 485 status attr.\n", __func__);

pr_err() ?  dev_err() ?

^ permalink raw reply

* Re: BTRFS thinks that a device is mounted
From: Nikos Voutsinas @ 2011-10-22 13:57 UTC (permalink / raw)
  To: linux-btrfs
In-Reply-To: <slrnja2h84.5ku.stephane.chazelas@spam.is.invalid>

> 2011-10-21, 00:39(+03), Nikos Voutsinas:
> [...]
>> ## Comment: Of course /dev/sdh is not mounted.
>> mount |grep /dev/sdh
>> root@lxc:~#
> [...]
>
> Note that mount(8) uses /etc/mtab to find out what is mounted.
> And if that file is not a symlink to /proc/mounts, the
> information is not necessarily correct.
>
> You can also have a look at /proc/mounts directly.
>

OK, I found what went wrong, however I am not sure whose fault this is and
If I am going to describe a case that is already known to this list.

To cut a long story short, the consecutive

root@btrfs:~# btrfs device add /dev/sdc /
root@btrfs:~# btrfs device delete /dev/sdc /

led to inconsistency between the contents of /proc/mounts and
/dev/disk/by-uuid (ie the mapping of UUIDs to devices).

Actually, "btrfs device add /dev/sdc /" changed the mapping of root's UUID
to point to /dev/sdc, and the system left it this way, even after the
"btrfs device delete /dev/sdc /". Thus I ended up with the following
situation.

root@btrfs:~# cat  /etc/mtab /proc/mounts |grep btrfs
/dev/sdd2 / btrfs rw 0 0
/dev/disk/by-uuid/cc8211ba-6f62-46d6-ba17-49250f06a941 / btrfs rw 0 0
root@btrfs:~#
root@btrfs:~# ls -l /dev/disk/by-uuid/cc8211ba-6f62-46d6-ba17-49250f06a941
lrwxrwxrwx 1 root root 9 Oct 22 16:13
/dev/disk/by-uuid/cc8211ba-6f62-46d6-ba17-49250f06a941 -> ../../sdc

Although this may be a udev issue, I think that the userspace tools of
btrfs should have handled this in a better way.

Nikos



^ permalink raw reply

* [Bug 36934] screen corruption after running a game
From: bugzilla-daemon @ 2011-10-22 14:00 UTC (permalink / raw)
  To: dri-devel
In-Reply-To: <bug-36934-502@http.bugs.freedesktop.org/>

https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #15 from almos <aaalmosss@gmail.com> 2011-10-22 07:00:31 PDT ---
Since I upgraded to mesa 7.11 I experience significantly less corruption than
with 7.10. It still happens sometimes, though. Now I removed the virtualbox
modules to give it a try.

Meanwhile, I also tried to reproduce the firefox image corruption in a vnc
screen, and it didn't happen, while running firefox normally is still bad. I
think it means this is not a bug in firefox, but in xorg/mesa/libdrm/linux
somewhere.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply

* Re: No line out on latest Mac Mini
From: John Frankish @ 2011-10-22 14:01 UTC (permalink / raw)
  To: alsa-devel@alsa-project.org; +Cc: kapouer@melix.org
In-Reply-To: <4EA2B49C.6090001@melix.org>

> Hi,
> i have an imac 12,2 (2011) and i had to change GPIO with hda_analyzer to get
> some sound on line out.
> 
> Jérémy.

Thanks - I see something like this with hda_analyser:

Global Input Amplifier Caps-> <- Global Output Amplifier Caps

GPIO
                  out-dir enable unsol sticky wake data
[0]
[1]            x             x                                                [x]
[2]
[3]            x             x                                                x

..where [1] data enables/disables line out and [3] data enables/disables the internal speaker.
[1] data was not checked and doing so got things working - a big thank you for this.

Line out continues to work after closing hda_analyser, but do you know what it actually changes so I
Can make it permanent across reboots?

^ permalink raw reply

* [Buildroot] [PATCH v4] package: add opencv
From: Mike Davies @ 2011-10-22 14:01 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1319130558-16555-1-git-send-email-s.martin49@gmail.com>

Hi,

I have tried your previous version (V3) and have a comment.

It seems to put over 32Mb into the target, that I think doesn't need to
be there, i.e.

[mike at ceri buildroot-2011.08]$ du -ch output/target/usr/share/opencv
56K	output/target/usr/share/opencv/lbpcascades
19M	output/target/usr/share/opencv/haarcascades
504K	output/target/usr/share/opencv/doc/vidsurv
14M	output/target/usr/share/opencv/doc
32M	output/target/usr/share/opencv
32M	total
[mike at ceri buildroot-2011.08]$ 

Certainly I don't want any documentation on my target system, and
there's 14Mb of that.

I built the system with just opencv selected, and nothing in the opencv
sub-menu selected.

Mike

^ permalink raw reply

* Re: [LARTC] LARTC mailing list
From: Andrew Beverley @ 2011-10-22 14:10 UTC (permalink / raw)
  To: Linux Advanced Routing & Traffic Control project
  Cc: linux-new-lists, netfilter, netdev
In-Reply-To: <4EA2BF3D.1010107@linuxsystems.it>

On Sat, 2011-10-22 at 15:03 +0200, Niccolò Belli wrote:
> Is someone still interested to bring LARTC to a new life?
> I'm sorry for the subscription but the list didn't work anymore and it 
> was unfeasible to CC 30+ addresses. Let me know if you want to 
> unsubscribe and you don't know how to.

Thanks for doing this Niccolo. However, I'd rather see it hosted at
vger.kernel.org for all the reasons previously outlined.

I was actually going to suggest a new list called net-users instead.
There is netdev, netfilter-devel and netfilter, but not a general
networking users list.

User questions do get asked on netdev, and some non-netfilter questions
get asked on the netfilter list, but it would seem sensible to have a
general networking users list that would include LARTC questions.

Comments anyone?

Andy




^ permalink raw reply

* Re: [LARTC] LARTC mailing list
From: Andrew Beverley @ 2011-10-22 14:10 UTC (permalink / raw)
  To: Linux Advanced Routing & Traffic Control project
  Cc: linux-new-lists, netfilter, netdev
In-Reply-To: <4EA2BF3D.1010107@linuxsystems.it>

On Sat, 2011-10-22 at 15:03 +0200, Niccolò Belli wrote:
> Is someone still interested to bring LARTC to a new life?
> I'm sorry for the subscription but the list didn't work anymore and it 
> was unfeasible to CC 30+ addresses. Let me know if you want to 
> unsubscribe and you don't know how to.

Thanks for doing this Niccolo. However, I'd rather see it hosted at
vger.kernel.org for all the reasons previously outlined.

I was actually going to suggest a new list called net-users instead.
There is netdev, netfilter-devel and netfilter, but not a general
networking users list.

User questions do get asked on netdev, and some non-netfilter questions
get asked on the netfilter list, but it would seem sensible to have a
general networking users list that would include LARTC questions.

Comments anyone?

Andy




^ permalink raw reply

* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Marek Vasut @ 2011-10-22 14:19 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <4EA2917B.30108@aribaud.net>

On Saturday, October 22, 2011 11:48:43 AM Albert ARIBAUD wrote:
> Le 22/10/2011 03:18, Marek Vasut a ?crit :
> > On Saturday, October 22, 2011 02:35:13 AM Albert ARIBAUD wrote:
> >> Hi Marek,
> >> 
> >> Le 22/10/2011 02:16, Marek Vasut a ?crit :
> >>> This patch series reworks the debug() and debugX() macro in
> >>> include/common.h to be compatible with GCC 4.6.
> >>> 
> >>> This series needs further discussion:
> >>> * Some files suffer size growth with gcc4.2, why ?
> >>> 
> >>>     - Possibility is that the GCC4.2 is incapable to optimize code out
> >>>     so deep
> >>> 
> >>> * Does this change break any platforms? Compile tested on PowerPC.
> >>> 
> >>>     - Please run MAKEALL on your platforms to test this.
> >> 
> >> Any git branch we could pull and rebase on our trees rather than am'ing
> >> 39 patches one by one?
> > 
> > Please try:
> > 
> > git://git.denx.de/u-boot-marex.git , "debug" branch.
> > 
> > Cheers
> 
> A differential 'MAKEALL arm' (ELDK42) show a sharp rise in board not
> building properly, from 74 to 141 (out of a total of 248).

This was expected ... will fix.
> 
> Of the 67 boards, many show , essentially due to a lot of printf format
> warnings such as:
> 
> ks8695eth.c: In function 'ks8695_eth_send':
> ks8695eth.c:199: warning: format '%x' expects type 'unsigned int', but
> argument 4 has type 'volatile void *'
> 
> (in cm4008, cm41xx), or
> 
> lcd.c: In function 'lcd_setmem':
> lcd.c:446: warning: format '%d' expects type 'int', but argument 2 has
> type 'u_long'
> lcd.c:446: warning: format '%d' expects type 'int', but argument 3 has
> type 'u_long'
> 
> (in at91sam9261ek_nandflash). Another, different, case is smdk2410:
> 
> s3c2410_nand.c: In function 's3c2410_hwcontrol':
> s3c2410_nand.c:59: error: 'DEBUG' undeclared (first use in this function)
> s3c2410_nand.c:59: error: (Each undeclared identifier is reported only once
> s3c2410_nand.c:59: error: for each function it appears in.)
> s3c2410_nand.c: In function 's3c2410_dev_ready':
> s3c2410_nand.c:86: error: 'DEBUG' undeclared (first use in this function)
> s3c2410_nand.c: In function 'board_nand_init':
> 
> Seems like you're trading some warnings against some others, depending
> on the compiler. :(

Not trading, the typechecking wasn't there and now that it is there, these kind 
of warnings keep popping up. Did you ever try to build those boards with DEBUG 
enabled?

Cheers

^ permalink raw reply

* Re: [Qemu-devel] gcc auto-omit-frame-pointer vs msvc longjmp
From: asmwarrior @ 2011-10-22 14:23 UTC (permalink / raw)
  To: Kai Tietz
  Cc: Mark Cave-Ayland, gcc@gcc.gnu.org, qemu-devel, xunxun, Bob Breuer,
	Richard Henderson
In-Reply-To: <CAEwic4Zey2f6fzSOAiGtyxuBnN2zSPwQCcDdTDdL8-DOiqC2GQ@mail.gmail.com>

On 2011-10-20 23:34, Kai Tietz wrote:
> Hi,
> 
> For trunk-version I have a tentative patch for this issue.  On 4.6.x
> and older branches this doesn't work, as here we can't differenciate
> that easy between ms- and sysv-abi.
> 
> But could somebody give this patch a try?
> 
> Regards,
> Kai
> 
> ChangeLog
> 
>          * config/i386/i386.c (ix86_frame_pointer_required): Enforce use of
>          frame-pointer for 32-bit ms-abi, if setjmp is used.
> 
> Index: i386.c
> ===================================================================
> --- i386.c      (revision 180099)
> +++ i386.c      (working copy)
> @@ -8391,6 +8391,10 @@
>     if (SUBTARGET_FRAME_POINTER_REQUIRED)
>       return true;
> 
> +  /* For older 32-bit runtimes setjmp requires valid frame-pointer.  */
> +  if (TARGET_32BIT_MS_ABI&&  cfun->calls_setjmp)
> +    return true;
> +
>     /* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER
>        turns off the frame pointer by default.  Turn it back on now if
>        we've not got a leaf function.  */
> 

I just see two related links about this issue:

see:
http://stackoverflow.com/questions/5887552/setjmp-and-omit-frame-pointer

and

http://connect.microsoft.com/VisualStudio/feedback/details/666704/visual-c-generates-incorrect-code-with-omit-frame-pointer-and-setjmp

I'm not sure microsoft has fix this issue.

asmwarrior
ollydbg from codeblocks' forum

^ permalink raw reply

* Re: [PATCH 0 of 6] pygrub fixes to support a Fedora 16 guest
From: Boris Derzhavets @ 2011-10-22 14:22 UTC (permalink / raw)
  To: xen-devel, M A Young; +Cc: Ian Campbell
In-Reply-To: <alpine.DEB.2.00.1110192358140.15667@vega-a.dur.ac.uk>


[-- Attachment #1.1: Type: text/plain, Size: 1983 bytes --]

Please, back port  to xen-4.1-testing.hg.

Boris

--- On Wed, 10/19/11, M A Young <m.a.young@durham.ac.uk> wrote:

From: M A Young <m.a.young@durham.ac.uk>
Subject: [Xen-devel] [PATCH 0 of 6] pygrub fixes to support a Fedora 16 guest
To: xen-devel@lists.xensource.com
Cc: "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Wednesday, October 19, 2011, 7:02 PM

This series contains patches that may be needed to allow pygrub to boot a Fedora 16 guest.

By default, Fedora 16 has GPT partitions and uses grub2. The first GPT partition is a grub2 boot partition to store the grub2 code. The second GPT partition contains the /boot filesystem with the kernel and initramfs files and grub2 configuration files. The remaining space is an LVM partition containing the remaining file systems.

The first patch allows pygrub to check all the GPT partitions, rather than just the first. This is a repost of the patch I submitted a few days ago with a slightly edited introductory text.

The second patch allows pygrub to find the grub2 configuration file which are in the /boot/grub2 directory on Fedora 16.

The third patch allows pygrub to handle partition references such as (hd0,gpt2) which occur in the Fedora 16 grub2 configuration file.

The fourth patch allows pygrub to parse grub2 configuration files with sub menus by ignoring the submenu line and the corresponding } line. A default Fedora 16 grub2 configuration file doesn't have sub menus but they do occur if the xen hypervisor is installed on the guest.

The fifth patch allows pygrub to parse grub2 configurations with the line
set default="${saved_entry}"
which can occur in the Fedora 16 grub2 configuration file.

The final patch adds a sample Fedora 16 grub2 configuration file
containing the problems fixed by patches 3,4 and 5.

    Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 2539 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

* Re: Problem with log which are corrupted and need help with hitcount and FORWARD rules
From: Andrew Beverley @ 2011-10-22 14:25 UTC (permalink / raw)
  To: Azerty Ytreza; +Cc: netfilter
In-Reply-To: <CACMGiwZ-4Q-xvVQOx3MM79U7YrwafcW+cMxsU932dRKfkM46GQ@mail.gmail.com>

On Sat, 2011-10-22 at 16:14 +0200, Azerty Ytreza wrote:
> "What exactly are you trying to achieve? If you're changing to a FORWARD
> rule then I assume that you are trying to adapt your rules in order to
> block connections destined for a remote server, rather than the local
> host?"
> 
> I want to limit the number of connections which passtrough the host.

Okay, in which case you do want FORWARD.

> Yes, I can block that on the remote server but I prefer on the local
> if it's possible.

Do you really mean "local" (in which case you want OUTPUT) or do you
just mean on your gateway/firewall server that all the traffic passes
through?

> 
> "Do you really mean UDP?"
> 
> No, it's an error sorry. I have copy/paste other rules and adapt rules
> but forget to change udp to tcp.

Okay, so it's working now?

> "You've got a mixture of INPUT and FORWARD. Is that what you want?
> Remember that packets will never transverse both the INPUT and FORWARD
> chains."
> 
> The port 443 is blocked by default it's for that which I open and
> after redirect. If I made only a FORWARD it's open directly the port
> without INPUT rules ?

It depends where you're blocking it. What's the default FORWARD rule?
ACCEPT?

The bottom line is that you need all your rules in FORWARD *or* INPUT. A
picture paints a thousand words:

http://jengelh.medozas.de/images/nf-packet-flow.png

Or for a simpler (out of date) version:

http://www.docum.org/docum.org/kptd/

> 
> 
> Thank you for your response !

No problem, but please put your responses in-line to the original email
rather than copying and pasting to the top! Oh, and copy the list as
well.

Andy



^ permalink raw reply

* [PATCH 0/3] ARM 4Kstacks: introduction
From: Andi Kleen @ 2011-10-22 14:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <yw1x1uu5p3sc.fsf@unicorn.mansr.com>


>> If system run for some time, sometimes it may be difficult for
>> memory allocator to allocate 2 continuous page frames even  there are
>> many spare page frames in system because of
>> fragment issue, so the patch does make sense. Anyway,
>> it provides one option for user to apply 4k stack to avoid
>> such kind of process creation failure.
>
> Can't page migration be used in these situations?

The kernel already uses it of course, assuming the pages are movable.
So if you are really worried about this, just define a movable zone.

-Andi

^ permalink raw reply

* Re: [PATCH 0/3] ARM 4Kstacks: introduction
From: Andi Kleen @ 2011-10-22 14:27 UTC (permalink / raw)
  To: "Måns Rullgård"
  Cc: Ming Lei, Arnd Bergmann, linux-arm-kernel, Tim Bird, Joe Perches,
	linux kernel, Andi Kleen, Russell King, Thomas Gleixner
In-Reply-To: <yw1x1uu5p3sc.fsf@unicorn.mansr.com>


>> If system run for some time, sometimes it may be difficult for
>> memory allocator to allocate 2 continuous page frames even  there are
>> many spare page frames in system because of
>> fragment issue, so the patch does make sense. Anyway,
>> it provides one option for user to apply 4k stack to avoid
>> such kind of process creation failure.
>
> Can't page migration be used in these situations?

The kernel already uses it of course, assuming the pages are movable.
So if you are really worried about this, just define a movable zone.

-Andi


^ permalink raw reply

* Re: [PATCH 1/2] drm/kms: Make i2c buses faster
From: Alex Deucher @ 2011-10-22 14:38 UTC (permalink / raw)
  To: Jean Delvare; +Cc: dri-devel
In-Reply-To: <201110212129.42810.jdelvare@suse.de>

On Fri, Oct 21, 2011 at 3:29 PM, Jean Delvare <jdelvare@suse.de> wrote:
> Hi Alex,
>
> On Friday 21 October 2011 08:05:48 pm Alex Deucher wrote:
>> On Fri, Oct 21, 2011 at 10:16 AM, Jean Delvare <jdelvare@suse.de>
>> > Does anyone know at which speed hardware I2C engines are running
>> > the DDC bus on various graphics cards?
>>
>> IIRC, we generally target the radeon hw i2c engines to run at 50 khz.
>
> Then it doesn't seem unreasonable to try and achieve the same for bit-
> banged I2C. That's exactly what my patch is doing.

Seems fine to me then.  I don't know why we set it so low to begin
with, but I'm certainly not an i2c expert.

Alex

>
> --
> Jean Delvare
> Suse L3
>

^ permalink raw reply

* tag process's future sockets for iptables rules?
From: p. awa @ 2011-10-22 14:44 UTC (permalink / raw)
  To: netfilter

i used to do redirection and filtering based on the uid of a packet's
local socket. the point was to transparently proxy an arbitrary process's
outbound tcp connections through tor[1]. it had a nice enough interface:

$ sudo torified-user wget http://example.com/

then i switched to filtering based on gid instead of uid: having only
the gid of regular files created by a process screwed with was less
intrusive. but it is all still a hack that becomes unwieldy when you
need more complex filtering rules.

so i wonder if netfilter provides a facility that would allow a process
to specify tags that are then added onto all sockets/connections/packets
this process and its children create in the future, and to filter based
upon those tags. something like:

| netfilter_add_tag("public-addresses-proxied-via-tor");
| netfilter_add_tag("internal-addresses-directly");
| netfilter_remove_tag("proxy-dns");
| execlp("wget", ...);

plus corresponding iptables rules:

# iptables ... --with-tag    public-addresses-proxied-via-tor \
               --with-tag    internal-addresses-directly \
               --without-tag proxy-dns ...

is there such a thing? of course it wouldn't have to be this interface
exactly, e.g. instead of strings the tags could be bits like connmark's
value/mask. there wouldn't be by any chance a way to to set a "default
connmark value" from inside a process, would there?

please note that i'm only asking about this tagging facility, and not
about the proxying use case above (which is merely a simplified example).

cheers

[1] https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy

^ permalink raw reply

* [U-Boot] ATM/13470/IDR
From: PRIME MINISTER'S OFFICE @ 2011-10-22 14:48 UTC (permalink / raw)
  To: u-boot

PRIME MINISTER'S OFFICE
TREASURY AND MINISTER FOR THE CIVIL SERVICE,
LONDON, UNITED KINGDOM.
 
Our ref: ATM/13470/IDR
Your ref:...Date: 22/10/2011
 
IMMEDIATE PAYMENT NOTIFICATION
 
I am The Rt Hon David Cameron MP,Prime Minister, First Lord of the Treasury and Minister for the Civil Service British Government. This letter is to officially inform you that (ATM Card Number 7302 7168 0041 0640) has been accredited with your favor. Your Personal Identification Number is 1090.

The VISA Card Value is ?2,000,000.00(Two Million, Great British Pounds Sterling).
This office will send to you an ATM/VISA CARD that you will use to withdraw your funds in any ATM MACHINE CENTER or Visa card outlet in the world with a maximum of ?5000 GBP daily.

Further more,You will be required to re-confirm the following information to enable;The Rt Hon William Hague MP First Secretary of State for British Foreign and Commonwealth Affairs 
Begin in processing of your VISA/ATM CARD to you in your country.

(1)Full names: 
(2)Address:
(3)Country: 
(4)Nationality: 
(5)Phone:
(6)Age: 
(7)Occupation: 
(8)Post Codes:
(9)Date: 

Rt Hon William Hague MP.
First Secretary of State for Foreign and Commonwealth Affairs
Email:atmcustomer.c at w.cn
Tel:+447024016930
 
TAKE NOTE: That you are warned to stop further communications with any other person(s) or office(s) different from the staff of the State for Foreign and Commonwealth Affairs to avoid hitches in receiving your payment.
 
Regards,
The Rt Hon David Cameron MP
Prime Minister

^ permalink raw reply

* [PATCH] ASoC: wm8400: Fix setting Fout clock divider for FLL Control 4
From: Axel Lin @ 2011-10-22 14:48 UTC (permalink / raw)
  To: linux-kernel; +Cc: Dimitris Papastamos, alsa-devel, Mark Brown, Liam Girdwood

What we want here is to clear the WM8400_FLL_OUTDIV_MASK bits then
OR with factors.outdiv.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
 sound/soc/codecs/wm8400.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sound/soc/codecs/wm8400.c b/sound/soc/codecs/wm8400.c
index dc13be2..f29bc26 100644
--- a/sound/soc/codecs/wm8400.c
+++ b/sound/soc/codecs/wm8400.c
@@ -1059,7 +1059,7 @@ static int wm8400_set_dai_pll(struct snd_soc_dai *codec_dai, int pll_id,
 	wm8400_write(codec, WM8400_FLL_CONTROL_3, factors.n);
 
 	reg = wm8400_read(codec, WM8400_FLL_CONTROL_4);
-	reg &= WM8400_FLL_OUTDIV_MASK;
+	reg &= ~WM8400_FLL_OUTDIV_MASK;
 	reg |= factors.outdiv;
 	wm8400_write(codec, WM8400_FLL_CONTROL_4, reg);
 
-- 
1.7.5.4

^ permalink raw reply related

* [PATCH] ASoC: wm8400: Fix setting Fout clock divider for FLL Control 4
From: Axel Lin @ 2011-10-22 14:48 UTC (permalink / raw)
  To: linux-kernel; +Cc: Mark Brown, Dimitris Papastamos, Liam Girdwood, alsa-devel

What we want here is to clear the WM8400_FLL_OUTDIV_MASK bits then
OR with factors.outdiv.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
 sound/soc/codecs/wm8400.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sound/soc/codecs/wm8400.c b/sound/soc/codecs/wm8400.c
index dc13be2..f29bc26 100644
--- a/sound/soc/codecs/wm8400.c
+++ b/sound/soc/codecs/wm8400.c
@@ -1059,7 +1059,7 @@ static int wm8400_set_dai_pll(struct snd_soc_dai *codec_dai, int pll_id,
 	wm8400_write(codec, WM8400_FLL_CONTROL_3, factors.n);
 
 	reg = wm8400_read(codec, WM8400_FLL_CONTROL_4);
-	reg &= WM8400_FLL_OUTDIV_MASK;
+	reg &= ~WM8400_FLL_OUTDIV_MASK;
 	reg |= factors.outdiv;
 	wm8400_write(codec, WM8400_FLL_CONTROL_4, reg);
 
-- 
1.7.5.4




^ permalink raw reply related

* Re: [PATCH v2] i2c: mxs: Let i2c-mxs be built for MX23
From: Wolfram Sang @ 2011-10-22 14:57 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Uwe Kleine-König, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	khali-PUYAD+kWke1g9hUCZPvPmw, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ, shawn.guo-KZfg59tc24xl57MIdRCFDg
In-Reply-To: <4EA1C128.106-KZfg59tc24xl57MIdRCFDg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]


> >> MX23 and MX28 share the same I2C block, so let i2c-mxs be built for MX23 too.
> >>
> >> Signed-off-by: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > arch/arm/mach-mxs/devices/platform-mxs-i2c.c doesn't support i.MX23 yet,
> > but still I think the change is correct.
> 
> Yes, I know. I plan to submit the I2C arch/arm/mach-mxs related patches next week. 
>  
> > Acked-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Still NACK (unless somebody can explain to me how PIOQUEUE could work on MX23).

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: Panic:: handle_irq_event_percpu
From: Sander Eikelenboom @ 2011-10-22 14:57 UTC (permalink / raw)
  To: Huang2, Wei; +Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk
In-Reply-To: <EE335F95F28A664DB4A21289D2AA053B01E6CBBD30@SAUSEXMBP01.amd.com>

Hello Wei,

Is this for xen 4.1.2 ?
All hunks of the patch seem to be rejected.

--
Sander


Wednesday, October 19, 2011, 8:27:55 PM, you wrote:

> This reminds me of 23768:09595fdf3638, which reverted WeiWang's patch of forcing perdev-intremap as default. Could you try the attached patch on your Xen 4.1 tree and test with patched xen.gz? 

> Thanks,
> -Wei

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Sander Eikelenboom
> Sent: Wednesday, October 19, 2011 12:30 PM
> To: Huang2, Wei
> Cc: xen-devel@lists.xensource.com; Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] Panic:: handle_irq_event_percpu

> Hello Wei,

> Result is that using only "1" or "1" in combination with "2" always result in SATA I/O errors, so that doesn't boot.

> Haven't tried rebooting a lot of times without iommu yet.
> (the reason i bought the 890fx board in the first place)
> Will try that a few times when i have some more time.

> --
> Sander

> Wednesday, October 19, 2011, 6:38:38 PM, you wrote:

>> It looks similar. 

>> Hi Sander, could you please test your system with the following options?

>> 1. iommu=amd-iommu-perdev-intremap in xen.gz GRUB entry
>> 2. pci=nosmi in pvops GRUB entry
>> 3. iommu=0 in xen.gz GRUB entry [optional, only if (1) doesn't work for you]

>> We were seeing an issue which was caused by messed-up interrupt remap table. George Dunlap's perdev interrupt map solved our problem.

>> Thanks,
>> -Wei

>> -----Original Message-----
>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
>> Sent: Wednesday, October 19, 2011 11:08 AM
>> To: Sander Eikelenboom; Huang2, Wei
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Panic:: handle_irq_event_percpu

>> On Tue, Oct 18, 2011 at 08:55:19PM +0200, Sander Eikelenboom wrote:
>>> Hi Konrad,
>>> 
>>> On my system (AND phenom x6, 8gb mem) running xen 4.1.2-rc3
>>> and a custom kernel based on:
>>> 
>>> - your linux-next branch
>>> - pulled in your apci/cpufreq branch
>>> - pulled in latest patches from linuses tree

>> Wei,
>> Are those similar to what you had been seeing?

>>> 
>>> I'm experiencing infrequent panics at boot (say 1 out of 10 or 20 boots), doesn't seem to matter if it's a cold or a warm boot.
>>> It always seem to happen during or shortly after booting. When it doesn't occur then, it can run for at least several days/weeks (haven't seen it panic then).
>>> It doesn't seem to happen at a particular point at or shortly after booting, but it happens before starting any guests
>>> 
>>> Unfortunately i haven't had serial console enabled at these times, but i have made some photo's.
>>> The first 3 times it locked completely before being able to print a stacktrace, the 4th time it did (although the photo is a bit unsharp).
>>> 
>>> 
>>> So all in all, it kind of strange, i hope you can figure something out from the stacktrace, if not, i will see if i can try with serial console attached.
>>> 
>>> --
>>> Sander





>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel









-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

^ permalink raw reply


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.