* [patch 2/7] mn10300: Remove unused mn10300_intc_* functions
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn10300-remove-unused-functions.patch --]
[-- Type: text/plain, Size: 1843 bytes --]
No users.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/include/asm/intctl-regs.h | 5 -----
arch/mn10300/kernel/irq.c | 25 -------------------------
2 files changed, 30 deletions(-)
Index: linux-next/arch/mn10300/include/asm/intctl-regs.h
===================================================================
--- linux-next.orig/arch/mn10300/include/asm/intctl-regs.h
+++ linux-next/arch/mn10300/include/asm/intctl-regs.h
@@ -60,11 +60,6 @@
#ifndef __ASSEMBLY__
extern void set_intr_level(int irq, u16 level);
-extern void mn10300_intc_set_level(unsigned int irq, unsigned int level);
-extern void mn10300_intc_clear(unsigned int irq);
-extern void mn10300_intc_set(unsigned int irq);
-extern void mn10300_intc_enable(unsigned int irq);
-extern void mn10300_intc_disable(unsigned int irq);
extern void mn10300_set_lateack_irq_type(int irq);
#endif
Index: linux-next/arch/mn10300/kernel/irq.c
===================================================================
--- linux-next.orig/arch/mn10300/kernel/irq.c
+++ linux-next/arch/mn10300/kernel/irq.c
@@ -252,31 +252,6 @@ void set_intr_level(int irq, u16 level)
__mask_and_set_icr(irq, GxICR_ENABLE, level);
}
-void mn10300_intc_set_level(unsigned int irq, unsigned int level)
-{
- set_intr_level(irq, NUM2GxICR_LEVEL(level) & GxICR_LEVEL);
-}
-
-void mn10300_intc_clear(unsigned int irq)
-{
- __mask_and_set_icr(irq, GxICR_LEVEL | GxICR_ENABLE, GxICR_DETECT);
-}
-
-void mn10300_intc_set(unsigned int irq)
-{
- __mask_and_set_icr(irq, 0, GxICR_REQUEST | GxICR_DETECT);
-}
-
-void mn10300_intc_enable(unsigned int irq)
-{
- mn10300_cpupic_unmask(irq);
-}
-
-void mn10300_intc_disable(unsigned int irq)
-{
- mn10300_cpupic_mask(irq);
-}
-
/*
* mark an interrupt to be ACK'd after interrupt handlers have been run rather
* than before
^ permalink raw reply
* [patch 0/7] mn10300: Convert to new irq_chip functions
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
Convert to new irq_chip functions and select GENERIC_HARDIRQS_NO_DEPRECATED
Untested due to lack of hardware and compiler.
Thanks,
tglx
^ permalink raw reply
* [patch 1/7] mn10300: Remove stale irq_chip.end - V2
From: Thomas Gleixner @ 2011-02-06 21:45 UTC (permalink / raw)
To: LKML; +Cc: David Howells
In-Reply-To: <20110206214441.438777646@linutronix.de>
[-- Attachment #1: mn10300-remove-stale-irq_chip-end.patch --]
[-- Type: text/plain, Size: 687 bytes --]
irq_chip.end got obsolete with the remnoval of __do_IRQ().
Might compiles this time, if i had a compiler ...
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/mn10300/kernel/mn10300-serial.c | 1 -
1 file changed, 1 deletion(-)
Index: linux-next/arch/mn10300/kernel/mn10300-serial.c
===================================================================
--- linux-next.orig/arch/mn10300/kernel/mn10300-serial.c
+++ linux-next/arch/mn10300/kernel/mn10300-serial.c
@@ -394,7 +394,6 @@ static struct irq_chip mn10300_serial_pi
.mask = mn10300_serial_mask_ack,
.mask_ack = mn10300_serial_mask_ack,
.unmask = mn10300_serial_nop,
- .end = mn10300_serial_nop,
};
^ permalink raw reply
* [PATCH] tinderclient: Remove it (obsoleted by oestats-client)
From: Yuri Bushmelev @ 2011-02-06 21:44 UTC (permalink / raw)
To: openembedded-devel
Tinderclient is unusable now and obsoleted by oestats-client. So we should
remove it from tree.
NOTE for Angstrom and Kaelios maintainers: this patch change your configs.
---
classes/tinderclient.bbclass | 389 ----------------------------------
conf/distro/include/angstrom.inc | 26 ---
conf/distro/include/kaeilos-2010.inc | 22 --
conf/distro/include/kaeilos.inc | 26 ---
conf/tinder.conf | 27 ---
recipes/bitbake/bitbake.inc | 2 +-
6 files changed, 1 insertions(+), 491 deletions(-)
delete mode 100644 classes/tinderclient.bbclass
delete mode 100644 conf/tinder.conf
diff --git a/classes/tinderclient.bbclass b/classes/tinderclient.bbclass
deleted file mode 100644
index 7ccc1f2..0000000
--- a/classes/tinderclient.bbclass
+++ /dev/null
@@ -1,389 +0,0 @@
-def tinder_http_post(d, server, selector, content_type, body):
- import httplib
- # now post it
- for i in range(0,5):
- try:
- proxy = data.getVar('HTTP_PROXY', d, True )
- if (proxy):
- if (proxy.endswith('/')):
- proxy = proxy[:-1]
- if (proxy.startswith('http://')):
- proxy = proxy[7:]
- h = httplib.HTTP(proxy)
- h.putrequest('POST', 'http://%s%s' % (server, selector))
- else:
- h = httplib.HTTP(server)
- h.putrequest('POST', selector)
- h.putheader('content-type', content_type)
- h.putheader('content-length', str(len(body)))
- h.endheaders()
- h.send(body)
- errcode, errmsg, headers = h.getreply()
- #print errcode, errmsg, headers
- return (errcode,errmsg, headers, h.file)
- except Exception, e:
- print "Error sending the report! ", e
- # try again
- pass
-
- # return some garbage
- return (-1, "unknown", "unknown", None)
-
-def tinder_form_data(bound, dict, log):
- output = []
- # for each key in the dictionary
- for name in dict:
- assert dict[name]
- output.append( "--" + bound )
- output.append( 'Content-Disposition: form-data; name="%s"' % name )
- output.append( "" )
- output.append( dict[name] )
- if log:
- output.append( "--" + bound )
- output.append( 'Content-Disposition: form-data; name="log"; filename="log.txt"' )
- output.append( '' )
- output.append( log )
- output.append( '--' + bound + '--' )
- output.append( '' )
-
- return "\r\n".join(output)
-
-def tinder_time_string():
- """
- Return the time as GMT
- """
- return ""
-
-def tinder_format_http_post(d,status,log):
- """
- Format the Tinderbox HTTP post with the data needed
- for the tinderbox to be happy.
- """
-
- import random
-
- # the variables we will need to send on this form post
- variables = {
- "tree" : data.getVar('TINDER_TREE', d, True),
- "machine_name" : data.getVar('TINDER_MACHINE', d, True),
- "os" : os.uname()[0],
- "os_version" : os.uname()[2],
- "compiler" : "gcc",
- "clobber" : data.getVar('TINDER_CLOBBER', d, True) or "0",
- "srcdate" : data.getVar('SRCDATE', d, True),
- "PN" : data.getVar('PN', d, True),
- "PV" : data.getVar('PV', d, True),
- "PR" : data.getVar('PR', d, True),
- "FILE" : data.getVar('FILE', d, True) or "N/A",
- "TARGETARCH" : data.getVar('TARGET_ARCH', d, True),
- "TARGETFPU" : data.getVar('TARGET_FPU', d, True) or "Unknown",
- "TARGETOS" : data.getVar('TARGET_OS', d, True) or "Unknown",
- "MACHINE" : data.getVar('MACHINE', d, True) or "Unknown",
- "DISTRO" : data.getVar('DISTRO', d, True) or "Unknown",
- }
-
- # optionally add the status
- if status:
- variables["status"] = str(status)
-
- # try to load the machine id
- # we only need on build_status.pl but sending it
- # always does not hurt
- try:
- f = file(data.getVar('TMPDIR',d,True)+'/tinder-machine.id', 'r')
- id = f.read()
- variables['machine_id'] = id
- except:
- pass
-
- # the boundary we will need
- boundary = "----------------------------------%d" % int(random.random()*1000000000000)
-
- # now format the body
- body = tinder_form_data( boundary, variables, log )
-
- return ("multipart/form-data; boundary=%s" % boundary),body
-
-
-def tinder_build_start(d):
- """
- Inform the tinderbox that a build is starting. We do this
- by posting our name and tree to the build_start.pl script
- on the server.
- """
- from bb import data
-
- # get the body and type
- content_type, body = tinder_format_http_post(d,None,None)
- server = data.getVar('TINDER_HOST', d, True )
- url = data.getVar('TINDER_URL', d, True )
-
- selector = url + "/xml/build_start.pl"
-
- #print "selector %s and url %s" % (selector, url)
-
- # now post it
- errcode, errmsg, headers, h_file = tinder_http_post(d,server,selector,content_type, body)
- #print errcode, errmsg, headers
- report = h_file.read()
-
- # now let us find the machine id that was assigned to us
- search = "<machine id='"
- report = report[report.find(search)+len(search):]
- report = report[0:report.find("'")]
-
- import bb
- bb.note("Machine ID assigned by tinderbox: %s" % report )
-
- # now we will need to save the machine number
- # we will override any previous numbers
- f = file(data.getVar('TMPDIR', d, True)+"/tinder-machine.id", 'w')
- f.write(report)
-
-
-def tinder_send_http(d, status, _log):
- """
- Send this log as build status
- """
- from bb import data
-
-
- # get the body and type
- server = data.getVar('TINDER_HOST', d, True )
- url = data.getVar('TINDER_URL', d, True )
-
- selector = url + "/xml/build_status.pl"
-
- # now post it - in chunks of 10.000 charachters
- new_log = _log
- while len(new_log) > 0:
- content_type, body = tinder_format_http_post(d,status,new_log[0:18000])
- errcode, errmsg, headers, h_file = tinder_http_post(d,server,selector,content_type, body)
- #print errcode, errmsg, headers
- #print h.file.read()
- new_log = new_log[18000:]
-
-
-def tinder_print_info(d):
- """
- Print the TinderBox Info
- Including informations of the BaseSystem and the Tree
- we use.
- """
-
- from bb import data
- import os
- # get the local vars
-
- time = tinder_time_string()
- ops = os.uname()[0]
- version = os.uname()[2]
- url = data.getVar( 'TINDER_URL' , d, True )
- tree = data.getVar( 'TINDER_TREE', d, True )
- branch = data.getVar( 'TINDER_BRANCH', d, True )
- srcdate = data.getVar( 'SRCDATE', d, True )
- machine = data.getVar( 'MACHINE', d, True )
- distro = data.getVar( 'DISTRO', d, True )
- bbfiles = data.getVar( 'BBFILES', d, True )
- tarch = data.getVar( 'TARGET_ARCH', d, True )
- fpu = data.getVar( 'TARGET_FPU', d, True )
- oerev = data.getVar( 'OE_REVISION', d, True ) or "unknown"
-
- # there is a bug with tipple quoted strings
- # i will work around but will fix the original
- # bug as well
- output = []
- output.append("== Tinderbox Info" )
- output.append("Time: %(time)s" )
- output.append("OS: %(ops)s" )
- output.append("%(version)s" )
- output.append("Compiler: gcc" )
- output.append("Tinderbox Client: 0.1" )
- output.append("Tinderbox Client Last Modified: yesterday" )
- output.append("Tinderbox Protocol: 0.1" )
- output.append("URL: %(url)s" )
- output.append("Tree: %(tree)s" )
- output.append("Config:" )
- output.append("branch = '%(branch)s'" )
- output.append("TARGET_ARCH = '%(tarch)s'" )
- output.append("TARGET_FPU = '%(fpu)s'" )
- output.append("SRCDATE = '%(srcdate)s'" )
- output.append("MACHINE = '%(machine)s'" )
- output.append("DISTRO = '%(distro)s'" )
- output.append("BBFILES = '%(bbfiles)s'" )
- output.append("OEREV = '%(oerev)s'" )
- output.append("== End Tinderbox Client Info" )
-
- # now create the real output
- return "\n".join(output) % vars()
-
-
-def tinder_print_env():
- """
- Print the environment variables of this build
- """
- from bb import data
- import os
-
- time_start = tinder_time_string()
- time_end = tinder_time_string()
-
- # build the environment
- env = ""
- for var in os.environ:
- env += "%s=%s\n" % (var, os.environ[var])
-
- output = []
- output.append( "---> TINDERBOX RUNNING env %(time_start)s" )
- output.append( env )
- output.append( "<--- TINDERBOX FINISHED (SUCCESS) %(time_end)s" )
-
- return "\n".join(output) % vars()
-
-def tinder_tinder_start(d, event):
- """
- PRINT the configuration of this build
- """
-
- time_start = tinder_time_string()
- config = tinder_print_info(d)
- #env = tinder_print_env()
- time_end = tinder_time_string()
- packages = " ".join( event.getPkgs() )
-
- output = []
- output.append( "---> TINDERBOX PRINTING CONFIGURATION %(time_start)s" )
- output.append( config )
- #output.append( env )
- output.append( "<--- TINDERBOX FINISHED PRINTING CONFIGURATION %(time_end)s" )
- output.append( "---> TINDERBOX BUILDING '%(packages)s'" )
- output.append( "<--- TINDERBOX STARTING BUILD NOW" )
-
- output.append( "" )
-
- return "\n".join(output) % vars()
-
-def tinder_do_tinder_report(event):
- """
- Report to the tinderbox:
- On the BuildStart we will inform the box directly
- On the other events we will write to the TINDER_LOG and
- when the Task is finished we will send the report.
-
- The above is not yet fully implemented. Currently we send
- information immediately. The caching/queuing needs to be
- implemented. Also sending more or less information is not
- implemented yet.
-
- We have two temporary files stored in the TMP directory. One file
- contains the assigned machine id for the tinderclient. This id gets
- assigned when we connect the box and start the build process the second
- file is used to workaround an EventHandler limitation. If BitBake is ran
- with the continue option we want the Build to fail even if we get the
- BuildCompleted Event. In this case we have to look up the status and
- send it instead of 100/success.
- """
- from bb.event import getName
- from bb import data, mkdirhier, build
- import os, glob
-
- # variables
- name = getName(event)
- log = ""
- status = 1
- # Check what we need to do Build* shows we start or are done
- if name == "BuildStarted":
- tinder_build_start(event.data)
- log = tinder_tinder_start(event.data,event)
-
- try:
- # truncate the tinder log file
- f = file(data.getVar('TINDER_LOG', event.data, True), 'w')
- f.write("")
- f.close()
- except:
- pass
-
- try:
- # write a status to the file. This is needed for the -k option
- # of BitBake
- g = file(data.getVar('TMPDIR', event.data, True)+"/tinder-status", 'w')
- g.write("")
- g.close()
- except IOError:
- pass
-
- # Append the Task-Log (compile,configure...) to the log file
- # we will send to the server
- if name == "TaskSucceeded" or name == "TaskFailed":
- log_file = glob.glob("%s/log.%s.*" % (data.getVar('T', event.data, True), event.task))
-
- if len(log_file) != 0:
- to_file = data.getVar('TINDER_LOG', event.data, True)
- log += "".join(open(log_file[0], 'r').readlines())
-
- # set the right 'HEADER'/Summary for the TinderBox
- if name == "TaskStarted":
- log += "---> TINDERBOX Task %s started\n" % event.task
- elif name == "TaskSucceeded":
- log += "<--- TINDERBOX Task %s done (SUCCESS)\n" % event.task
- elif name == "TaskFailed":
- log += "<--- TINDERBOX Task %s failed (FAILURE)\n" % event.task
- elif name == "PkgStarted":
- log += "---> TINDERBOX Package %s started\n" % data.getVar('PF', event.data, True)
- elif name == "PkgSucceeded":
- log += "<--- TINDERBOX Package %s done (SUCCESS)\n" % data.getVar('PF', event.data, True)
- elif name == "PkgFailed":
- if not data.getVar('TINDER_AUTOBUILD', event.data, True) == "0":
- build.exec_func('do_clean', event.data)
- log += "<--- TINDERBOX Package %s failed (FAILURE)\n" % data.getVar('PF', event.data, True)
- status = 200
- # remember the failure for the -k case
- h = file(data.getVar('TMPDIR', event.data, True)+"/tinder-status", 'w')
- h.write("200")
- elif name == "BuildCompleted":
- log += "Build Completed\n"
- status = 100
- # Check if we have a old status...
- try:
- h = file(data.getVar('TMPDIR',event.data,True)+'/tinder-status', 'r')
- status = int(h.read())
- except:
- pass
-
- elif name == "MultipleProviders":
- log += "---> TINDERBOX Multiple Providers\n"
- log += "multiple providers are available (%s);\n" % ", ".join(event.getCandidates())
- log += "consider defining PREFERRED_PROVIDER_%s\n" % event.getItem()
- log += "is runtime: %d\n" % event.isRuntime()
- log += "<--- TINDERBOX Multiple Providers\n"
- elif name == "NoProvider":
- log += "Error: No Provider for: %s\n" % event.getItem()
- log += "Error:Was Runtime: %d\n" % event.isRuntime()
- status = 200
- # remember the failure for the -k case
- h = file(data.getVar('TMPDIR', event.data, True)+"/tinder-status", 'w')
- h.write("200")
-
- # now post the log
- if len(log) == 0:
- return
-
- # for now we will use the http post method as it is the only one
- log_post_method = tinder_send_http
- log_post_method(event.data, status, log)
-
-
-# we want to be an event handler
-addhandler tinderclient_eventhandler
-python tinderclient_eventhandler() {
- from bb import note, error, data
- from bb.event import getName
-
- if e.data is None or getName(e) == "MsgNote":
- return
-
- do_tinder_report = data.getVar('TINDER_REPORT', e.data, True)
- if do_tinder_report and do_tinder_report == "1":
- tinder_do_tinder_report(e)
-}
diff --git a/conf/distro/include/angstrom.inc b/conf/distro/include/angstrom.inc
index 6d7770b..5a02723 100644
--- a/conf/distro/include/angstrom.inc
+++ b/conf/distro/include/angstrom.inc
@@ -157,32 +157,6 @@ DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"
DISTRO_CHECK := "${@bb.data.getVar("DISTRO_VERSION",d,1) or bb.fatal('Remove this line or set a dummy DISTRO_VERSION if you really want to build an unversioned distro')}"
-# Configuration for tinderbox, so people only need:
-# INHERIT += "tinderclient"
-# in their local.conf
-
-#Name of the client
-TINDER_MACHINE = "${MACHINE}-${LIBC}-build-image"
-
-# Which lof file to write to, which tree to report to
-TINDER_LOG = "${TMPDIR}/tinder.log"
-TINDER_TREE = "Angstrom"
-
-# HTTP posting
-TINDER_HOST ?= "ewi546.ewi.utwente.nl"
-TINDER_URL ?= "/tinderbox"
-
-# Which branch do we build
-TINDER_BRANCH = "org.openembedded.dev"
-
-## Clobbing
-## 0 for rebuilding everything from scratch
-## 1 for incremental builds
-TINDER_CLOBBER = "1"
-
-## Do a report at all
-TINDER_REPORT = "1"
-
# Configuration for seppuku autobuilder, people only need to put:
# INHERIT += "seppuku oestats-client"
# SEPPUKU_USER = "your_bugzilla@user.id"
diff --git a/conf/distro/include/kaeilos-2010.inc b/conf/distro/include/kaeilos-2010.inc
index 061039d..fe42858 100644
--- a/conf/distro/include/kaeilos-2010.inc
+++ b/conf/distro/include/kaeilos-2010.inc
@@ -120,28 +120,6 @@ DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"
# KaeilOS *always* has some form of release config, so error out if someone thinks he knows better
DISTRO_CHECK := "${@bb.data.getVar("DISTRO_VERSION",d,1) or bb.fatal('Remove this line or set a dummy DISTRO_VERSION if you really want to build an unversioned distro')}"
-# Configuration for tinderbox, so people only need:
-# INHERIT += "tinderclient"
-# in their local.conf
-
-#Name of the client
-TINDER_MACHINE = "${MACHINE}-${LIBC}-build-image"
-
-# Which lof file to write to, which tree to report to
-TINDER_LOG = "${TMPDIR}/tinder.log"
-TINDER_TREE = "KaeilOS"
-
-# Which branch do we build
-TINDER_BRANCH = "org.openembedded.dev"
-
-## Clobbing
-## 0 for rebuilding everything from scratch
-## 1 for incremental builds
-TINDER_CLOBBER = "1"
-
-## Do a report at all
-TINDER_REPORT = "1"
-
OESTATS_SERVER ?= "tinderbox.openembedded.org"
# We want images supporting the following features (for task-base)
diff --git a/conf/distro/include/kaeilos.inc b/conf/distro/include/kaeilos.inc
index df4c069..848614f 100644
--- a/conf/distro/include/kaeilos.inc
+++ b/conf/distro/include/kaeilos.inc
@@ -161,32 +161,6 @@ DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"
DISTRO_CHECK := "${@bb.data.getVar("DISTRO_VERSION",d,1) or bb.fatal('Remove this line or set a dummy DISTRO_VERSION if you really want to build an unversioned distro')}"
-# Configuration for tinderbox, so people only need:
-# INHERIT += "tinderclient"
-# in their local.conf
-
-#Name of the client
-TINDER_MACHINE = "${MACHINE}-${LIBC}-build-image"
-
-# Which lof file to write to, which tree to report to
-TINDER_LOG = "${TMPDIR}/tinder.log"
-TINDER_TREE = "KaeilOS"
-
-# HTTP posting
-#TINDER_HOST ?= "ewi546.ewi.utwente.nl"
-#TINDER_URL ?= "/tinderbox"
-
-# Which branch do we build
-TINDER_BRANCH = "org.openembedded.dev"
-
-## Clobbing
-## 0 for rebuilding everything from scratch
-## 1 for incremental builds
-TINDER_CLOBBER = "1"
-
-## Do a report at all
-TINDER_REPORT = "1"
-
# Configuration for seppuku autobuilder, people only need to put:
# INHERIT += "seppuku oestats-client"
# SEPPUKU_USER = "your_bugzilla@user.id"
diff --git a/conf/tinder.conf b/conf/tinder.conf
deleted file mode 100644
index 614ed89..0000000
--- a/conf/tinder.conf
+++ /dev/null
@@ -1,27 +0,0 @@
-INHERIT += "tinderclient"
-
-
-#Name of the client
-#TINDER_MACHINE = "Test-NameOfClient-build-image"
-
-
-# Which lof file to write to, which tree to report to
-#TINDER_LOG = "${TMPDIR}/tinder.log"
-#TINDER_TREE = "OpenEmbeddedBuilds"
-
-
-# HTTP posting
-#TINDER_HOST = "ewi546.ewi.utwente.nl"
-#TINDER_URL = "/tinderbox"
-
-# Which branch do we build
-#TINDER_BRANCH = "org.openembedded.dev"
-
-# Clobbing
-# 0 for rebuilding everything from scratch
-# 1 for incremental builds
-#TINDER_CLOBBER = "0"
-
-# Do a report at all
-#TINDER_REPORT = "1"
-
diff --git a/recipes/bitbake/bitbake.inc b/recipes/bitbake/bitbake.inc
index 67dc6a5..97983ce 100644
--- a/recipes/bitbake/bitbake.inc
+++ b/recipes/bitbake/bitbake.inc
@@ -12,7 +12,7 @@ SUMMARY = "BitBake build tool"
RDEPENDS_${PN} += "python-shell python-lang python-textutils python-pickle python-crypt python-netclient"
# crypt for md5
-# netclient for tinderclient.bbclass
+# netclient for oestats-client.bbclass (urllib2)
# We don't need a toolchain...
INHIBIT_DEFAULT_DEPS = "1"
--
1.7.2.3
^ permalink raw reply related
* [U-Boot] [GIT PULL] u-boot-mpc83xx - couple of minor fixes
From: Wolfgang Denk @ 2011-02-06 21:42 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110205172435.405b1f20.kim.phillips@freescale.com>
Dear Kim Phillips,
In message <20110205172435.405b1f20.kim.phillips@freescale.com> you wrote:
> Wolfgang Denk,
>
> Please pull a couple of minor fixes for 83xx:
>
> The following changes since commit f69b980d108b5f15ca7dd3f4284d5a66488c3625:
>
> Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2011-02-04 21:44:46 +0100)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-mpc83xx.git master
>
> Joakim Tjernlund (1):
> mpc83xx: Use correct register to calculate clocks.
>
> Leo Liu (1):
> mpc83xx: fix pcie configuration space read/write
>
> arch/powerpc/cpu/mpc83xx/pcie.c | 19 ++++++++++++++++++-
> arch/powerpc/cpu/mpc83xx/speed.c | 15 ++++++++-------
> include/mpc83xx.h | 7 +++++++
> include/pci.h | 2 ++
> 4 files changed, 35 insertions(+), 8 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is easier to write an incorrect program than understand a correct
one.
^ permalink raw reply
* [U-Boot] Pull request: u-boot-usb
From: Wolfgang Denk @ 2011-02-06 21:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTi=jSxEVBr-32gw9XbfxohYKGaeDhZFniziQa-im@mail.gmail.com>
Dear Remy Bohmer,
In message <AANLkTi=jSxEVBr-32gw9XbfxohYKGaeDhZFniziQa-im@mail.gmail.com> you wrote:
> The following changes since commit f69b980d108b5f15ca7dd3f4284d5a66488c3625:
>
> Merge branch 'master' of git://git.denx.de/u-boot-nand-flash
> (2011-02-04 21:44:46 +0100)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-usb.git master
>
> Alexander Holler (2):
> USB: Fix device stati for removable and powerctrl (typo)
> USB: Change the necessary defines to get debug output
>
> common/usb.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's not an optical illusion, it just looks like one. -- Phil White
^ permalink raw reply
* [U-Boot] [GIT PULL] lease pull u-boot-mpc85xx.git
From: Wolfgang Denk @ 2011-02-06 21:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <Pine.LNX.4.64.1102041449150.1920@localhost.localdomain>
Dear Kumar Gala,
In message <Pine.LNX.4.64.1102041449150.1920@localhost.localdomain> you wrote:
> Some bug fix and errata fixes.
>
> - k
>
> The following changes since commit 42d44f631c4e8e5359775bdc098f2fffde4e5c05:
>
> Prepare v2011.03-rc1 (2011-02-02 22:37:32 +0100)
>
> are available in the git repository at:
> git://git.denx.de/u-boot-mpc85xx.git master
>
> Kumar Gala (3):
> powerpc/85xx: Enable ESDHC111 Erratum on P2010/P2020 SoCs
> fsl_esdhc: Add the workaround for erratum ESDHC-A001 (enable on P2020)
> powerpc/8xxx: Fix possible compile issue related to P1013
>
> York Sun (5):
> powerpc/85xx: Remove unnecessary polling loop from DDR init
> powerpc/85xx: Enable Errata command on MPC8572DS
> powerpc/85xx: Rename MPC8572 DDR erratum to DDR115
> powerpc/mpc85xx: implement workaround for errata DDR111 and DDR134
> powerpc/85xx: Enable ECC on MPC8572DS
>
> arch/powerpc/cpu/mpc85xx/Makefile | 2 +-
> arch/powerpc/cpu/mpc85xx/cmd_errata.c | 11 +++-
> arch/powerpc/cpu/mpc85xx/ddr-gen3.c | 111 +++++++++++++++++++++++++++-
> arch/powerpc/include/asm/config_mpc85xx.h | 6 ++
> arch/powerpc/include/asm/fsl_ddr_sdram.h | 5 ++
> drivers/mmc/fsl_esdhc.c | 5 ++
> include/configs/MPC8572DS.h | 3 +-
> 7 files changed, 136 insertions(+), 7 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The question of whether a computer can think is no more interesting
than the question of whether a submarine can swim"
- Edsgar W. Dijkstra
^ permalink raw reply
* [Bug 33887] nouveau causes graphic corruption were you cant do anything
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-02-06 21:36 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-33887-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33887
--- Comment #18 from Xavier <shiningxc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2011-02-06 13:36:21 PST ---
(In reply to comment #17)
> I read the mmiotrace.txt file on how to use the kernel functionality.
> Can you tell me what actions exactly would be useful to be traced after the WM
> is started.
>
> It is written :
> "During tracing you can place comments (markers) into the trace by
> $ echo "X is up" > /sys/kernel/debug/tracing/trace_marker
> This makes it easier to see which part of the (huge) trace corresponds to
> which action. It is recommended to place descriptive markers about what you
> do."
> But what actions exactly to do during the trace process ?
>
> And :
> "Please, pack into a compressed archive the trace file and a free description
> about what you do during the trace."
> Again what is useful to do ?
>
AFAIK with nouveau, you get corruption just by starting X.
So I think you just need to start X with the blob, mark X is up in the trace,
and stop.
> Can you also precise to me the format of the name of the archive file.
> "The name of the archive file should contain the PCI id and GPU family, or the
> commercial name of your card."
> Can you give an example of name please ?
>
> Again :
> "If you are doing a trace for a driver project, e.g. Nouveau, you should also
> do the following before sending your results:
> $ lspci -vvv > lspci.txt
> $ dmesg > dmesg.txt
> $ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt
> and then send the .tar.gz file. The trace compresses considerably. Replace
> "pciid" and "nick" with the PCI ID or model name of your piece of hardware
> under investigation and your nickname."
> I would like an example of name of the tarball file.
$ lspci -n -d 10de:
01:00.0 0300: 10de:0407 (rev a1)
-> the pci id of my card is 0407 (10de is vendor id, nvidia)
$ dmesg | grep generation
[11562.063550] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card
(0x084700a2)
-> generation is nv50, codename nv84.
So in my case I would just call it nv84-0407-shining-mmiotrace.tar.gz
--
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: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in rfc4106_set_hash_subkey().
From: Jesper Juhl @ 2011-02-06 21:33 UTC (permalink / raw)
To: Herbert Xu
Cc: Struk, Tadeusz, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, x86@kernel.org, H. Peter Anvin,
Ingo Molnar, Thomas Gleixner, David S. Miller, Huang, Ying,
Hoban, Adrian, Paoloni, Gabriele, O Mahony, Aidan
In-Reply-To: <20110206204829.GA12652@gondor.apana.org.au>
On Mon, 7 Feb 2011, Herbert Xu wrote:
> On Sun, Feb 06, 2011 at 09:34:33PM +0100, Jesper Juhl wrote:
> > On Mon, 7 Feb 2011, Herbert Xu wrote:
> >
> > > On Sun, Feb 06, 2011 at 08:43:22PM +0100, Jesper Juhl wrote:
> > > >
> > > > Herbert: If Tadeusz agrees, could you please replace the patch you merged
> > > > with the one above?
> > >
> > > Please send an incremental patch.
> > >
> > Sure thing. What would you like it based on exactly?
>
> The current cryptodev-2.6 tree should do.
>
Here goes.
Fix up previous patch that attempted to fix a mem leak in
rfc4106_set_hash_subkey. The previous patch was flawed in that the 'goto
out' would still leak.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
aesni-intel_glue.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index e013552..4a8c015 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -874,7 +874,7 @@ rfc4106_set_hash_subkey(u8 *hash_subkey, const u8 *key, unsigned int key_len)
ret = crypto_ablkcipher_setkey(ctr_tfm, key, key_len);
if (ret)
- goto out;
+ goto out_free_ablkcipher;
req = ablkcipher_request_alloc(ctr_tfm, GFP_KERNEL);
if (!req) {
@@ -916,7 +916,6 @@ out_free_request:
kfree(req_data);
out_free_ablkcipher:
crypto_free_ablkcipher(ctr_tfm);
-out:
return ret;
}
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* Re: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in rfc4106_set_hash_subkey().
From: Jesper Juhl @ 2011-02-06 21:33 UTC (permalink / raw)
To: Herbert Xu
Cc: Struk, Tadeusz, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, x86@kernel.org, H. Peter Anvin,
Ingo Molnar, Thomas Gleixner, David S. Miller, Huang, Ying,
Hoban, Adrian, Paoloni, Gabriele, O Mahony, Aidan
In-Reply-To: <20110206204829.GA12652@gondor.apana.org.au>
On Mon, 7 Feb 2011, Herbert Xu wrote:
> On Sun, Feb 06, 2011 at 09:34:33PM +0100, Jesper Juhl wrote:
> > On Mon, 7 Feb 2011, Herbert Xu wrote:
> >
> > > On Sun, Feb 06, 2011 at 08:43:22PM +0100, Jesper Juhl wrote:
> > > >
> > > > Herbert: If Tadeusz agrees, could you please replace the patch you merged
> > > > with the one above?
> > >
> > > Please send an incremental patch.
> > >
> > Sure thing. What would you like it based on exactly?
>
> The current cryptodev-2.6 tree should do.
>
Here goes.
Fix up previous patch that attempted to fix a mem leak in
rfc4106_set_hash_subkey. The previous patch was flawed in that the 'goto
out' would still leak.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
aesni-intel_glue.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index e013552..4a8c015 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -874,7 +874,7 @@ rfc4106_set_hash_subkey(u8 *hash_subkey, const u8 *key, unsigned int key_len)
ret = crypto_ablkcipher_setkey(ctr_tfm, key, key_len);
if (ret)
- goto out;
+ goto out_free_ablkcipher;
req = ablkcipher_request_alloc(ctr_tfm, GFP_KERNEL);
if (!req) {
@@ -916,7 +916,6 @@ out_free_request:
kfree(req_data);
out_free_ablkcipher:
crypto_free_ablkcipher(ctr_tfm);
-out:
return ret;
}
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* [U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment
From: Grant Erickson @ 2011-02-06 21:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <C974475E.23E4D%gerickson@nuovations.com>
On 2/6/11 12:41 PM, Grant Erickson wrote:
> I recently updated my TI AM37x EVM from U-Boot 2010.09 to 2010.12 and noticed
> that, in doing so, saveenv / env save no longer seems to work. The following
> example demonstrates [ELIDED]:
I subsequently found the following patch and commit:
http://www.mail-archive.com/u-boot at lists.denx.de/msg46834.html
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=920a5dd2325438a82b6ac8102c5a
5e0c43276fd;hp=42d44f631c4e8e5359775bdc098f2fffde4e5c05
However, it's not clear how this patch can reasonably work outside of random
chance:
// Allocate a new environment on the stack. The environment structure is
// whatever random data is already on the stack.
env_t env_new;
...
// At this point, the data field will be initialized; however, crc and
// flags are still random data.
res = (char *)&env_new.data;
len = hexport_r(&env_htab, '\0', &res, ENV_SIZE);
// The crc field is now set.
env_new.crc = crc32(0, env_new.data, ENV_SIZE);
// Preincrement random data.
++env_new.flags; /* increase the serial */
Unfortunately, preincrementing random data won't replicate the behavior of
2010.09, where the flags field was referenced through a global env_ptr such
that flag manipulation was handled (more) coherently as the environment was
read and written.
Best,
Grant
^ permalink raw reply
* [Bug 33792] [r600g] Evergreen vertex shaders transform vertices incorrectly in wine programs
From: bugzilla-daemon @ 2011-02-06 21:26 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-33792-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33792
--- Comment #11 from Rubén Fernández <rubenf3000@gmail.com> 2011-02-06 13:26:53 PST ---
Aside from Portal and Tales of Monkey Island, all the other games work
perfectly now, thanks to Henri's patch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Bug 33792] [r600g] Evergreen vertex shaders transform vertices incorrectly in wine programs
From: bugzilla-daemon @ 2011-02-06 21:24 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-33792-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33792
--- Comment #10 from Rubén Fernández <rubenf3000@gmail.com> 2011-02-06 13:24:37 PST ---
Created an attachment (id=43010)
--> (https://bugs.freedesktop.org/attachment.cgi?id=43010)
Output log after applying Henri Verbeet's patch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Bug 33792] [r600g] Evergreen vertex shaders transform vertices incorrectly in wine programs
From: bugzilla-daemon @ 2011-02-06 21:23 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-33792-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33792
--- Comment #9 from Rubén Fernández <rubenf3000@gmail.com> 2011-02-06 13:23:46 PST ---
Created an attachment (id=43009)
--> (https://bugs.freedesktop.org/attachment.cgi?id=43009)
Screenshot after applying Henri Verbeet's patch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Bug 33792] [r600g] Evergreen vertex shaders transform vertices incorrectly in wine programs
From: bugzilla-daemon @ 2011-02-06 21:22 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-33792-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33792
--- Comment #8 from Rubén Fernández <rubenf3000@gmail.com> 2011-02-06 13:22:21 PST ---
(In reply to comment #7)
> This may be similar to bug 31667, does
> https://bugs.freedesktop.org/attachment.cgi?id=42992 make it any better?
Your patch makes the errors go away in three of the five games I tested for the
error: Call of Cthulhu, Sam & Max, and Back to the Future.
Portal seems to be unaffected, and Tales of Monkey Island continues to
transform the vertices incorrectly, yet in a different way than before; I'll
attach a new screenshot and log for the latter.
So yes, I agree this is, at least in part, the same bug as 31667.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: Numonyx NOR and chip->mutex bug?
From: Joakim Tjernlund @ 2011-02-06 21:20 UTC (permalink / raw)
To: Michael Cashwell; +Cc: linux-mtd, Holger brunck, stefan.bigler
In-Reply-To: <0488D3BA-7BA3-4E98-B289-3F3D1DB485D4@prograde.net>
Michael Cashwell <mboards@prograde.net> wrote on 2011/02/06 22:13:40:
>
> On Feb 6, 2011, at 12:29 PM, Joakim Tjernlund wrote:
>
> > Michael Cashwell <mboards@prograde.net> wrote on 2011/02/06 16:49:53:
> >
> >> That's clearly what's happening in Stefan's trace when thread 465 writes 0xe8 and the next write is 0x70 by thread 209. Such a sequence is absolutely illegal (for the flash) and the latter thread is the problem. If we could get a stack trace for that map_write 0x70 I think we'd find the thread
awoke and touched the chip without verifying the state first. The question is why.
> >
> > Without my patch it is clear that you do end up with this problem. The first time one enter the for(;;) loop the driver reads out status from the chip before checking chip->state. This of course assumes that dropping the lock earlier may cause a schedule. So far Stefans tests indicates this to
be true.
>
> Yes, it was your patch and his log that lead me down that path!
>
> >> One last idea.
> >>
> >> The whole for(;;) loop in inval_cache_and_wait_for_operation() looks odd to me. Continuing with your idea of moving the chip->state while loop first, I see other problems. It seems to me that anywhere we drop and retake the chip mutex the very next thing needs to be the state check loop. Any
break in holding that mutex means we must go back to the top and check state again.
> >>
> >> I don't think the code as written does that. I have a completely reordered version of this function. (It didn't fix my issue but I think mine is something else.) On Monday I'll send that to you so you can consider it.
> >
> > Yes, it is a bit odd. In addition to my patch one could move the erase suspend tests before the if(!timeo) test.
>
> Precisely. I suspect you may well already have my reordered version. :-)
hehe, lets se(the barrier() is probably useless):
diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index e89f2d0..73e29a3 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -1243,12 +1243,34 @@ static int inval_cache_and_wait_for_operation(
timeo = 500000;
reset_timeo = timeo;
sleep_time = chip_op_time / 2;
-
+ barrier(); /* make sure chip->state gets reloaded */
for (;;) {
+ if (chip->state != chip_state) {
+ /* Someone's suspended the operation: sleep */
+ DECLARE_WAITQUEUE(wait, current);
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ add_wait_queue(&chip->wq, &wait);
+ mutex_unlock(&chip->mutex);
+ schedule();
+ remove_wait_queue(&chip->wq, &wait);
+ mutex_lock(&chip->mutex);
+ continue;
+ }
+
status = map_read(map, cmd_adr);
if (map_word_andequal(map, status, status_OK, status_OK))
break;
+ if (chip->erase_suspended && chip_state == FL_ERASING) {
+ /* Erase suspend occured while sleep: reset timeout */
+ timeo = reset_timeo;
+ chip->erase_suspended = 0;
+ }
+ if (chip->write_suspended && chip_state == FL_WRITING) {
+ /* Write suspend occured while sleep: reset timeout */
+ timeo = reset_timeo;
+ chip->write_suspended = 0;
+ }
if (!timeo) {
map_write(map, CMD(0x70), cmd_adr);
chip->state = FL_STATUS;
@@ -1272,27 +1294,6 @@ static int inval_cache_and_wait_for_operation(
timeo--;
}
mutex_lock(&chip->mutex);
-
- while (chip->state != chip_state) {
- /* Someone's suspended the operation: sleep */
- DECLARE_WAITQUEUE(wait, current);
- set_current_state(TASK_UNINTERRUPTIBLE);
- add_wait_queue(&chip->wq, &wait);
- mutex_unlock(&chip->mutex);
- schedule();
- remove_wait_queue(&chip->wq, &wait);
- mutex_lock(&chip->mutex);
- }
- if (chip->erase_suspended && chip_state == FL_ERASING) {
- /* Erase suspend occured while sleep: reset timeout */
- timeo = reset_timeo;
- chip->erase_suspended = 0;
- }
- if (chip->write_suspended && chip_state == FL_WRITING) {
- /* Write suspend occured while sleep: reset timeout */
- timeo = reset_timeo;
- chip->write_suspended = 0;
- }
}
/* Done and happy. */
>
> >>> Oh, one more thing, possibly one needs to add cpu_relax() or similar to force gcc to reload chip->state in the while loop?
> >>
> >> I was also wondering about possible gcc optimization issues. I'm on 4.5.2 and that worked for me with the 2003 flash part. The same binaries fail with the 2008 parts, so, I don't know.
> >
> > Very recent gcc, I am 3.4.6 but recently I began testing a little with 4.5.2. I do think I will wait for 4.5.3
>
> I tried 4.5.1 but it failed for other reasons. I submitted bug reports to gnu and a fix appeared (finally) in 4.5.2. It's been good so far but I'm always mindful of that issue.
>
> Staying current is a two edge sword. In general, later gccs have better code analysis and warnings which are valuable even if we ship using an older version.
Precisely, but later gcc is worse optimizing trivial code.
>
> >> Keep in mind that chip->state is not a hardware access. It's just another struct member. And I think that the rules are that any function call counts as a sequence point and gcc isn't allowed to think it knows what the result is and must reload it.
> >>
> >> Lastly, consider the direction of the behavior. If we're in the state-check while loop then we got there because the two things were NOT equal. If an optimization error is causing a stale value to be compared wouldn't the observed behavior be that it remains not equal? (If it's not reloaded
then how could it change?)
> >>
> >> I'd expect an optimization error like that to get us stuck in the while loop, not exit from it prematurely.
> >
> > Yes, all true. I wonder though if the mutex lock/unlock counts as a reload point? These are usually some inline asm. If not one could possibly argue that the first chip->state access, before entering the while body is using an old value.
>
> Yes, how inlines interact with sequence points has never been entirely clear to me. Especially since the compiler is free to inline something I didn't tell it to and to ignore me telling to inline if it wants to.
>
> I *think* the rules are semantic. If it's written (preprocessor aside) to look like a function call then it counts as a sequence point even if it ends up being inlined. But that's all quite beyond anything I can say for sure!
That makes sense too.
>
> >> Makes me head hurt!
> >
> > You are not alone :)
>
> So collectively maybe we can make it hurt less. That's my theory, anyway, and I'm sticking to it.
:)
^ permalink raw reply related
* [U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment
From: Wolfgang Denk @ 2011-02-06 21:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <C974475E.23E4D%gerickson@nuovations.com>
Dear Grant Erickson,
In message <C974475E.23E4D%gerickson@nuovations.com> you wrote:
> I recently updated my TI AM37x EVM from U-Boot 2010.09 to 2010.12 and
> noticed that, in doing so, saveenv / env save no longer seems to work. The
> following example demonstrates:
See git commit
920a5dd 2011-02-02 16:14:08 -0600 NAND: Fix saving of redundand environment
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Heavier than air flying machines are impossible.
-- Lord Kelvin, President, Royal Society, c. 1895
^ permalink raw reply
* [U-Boot] U-boot 1.1.3 and ADS Graphics Client Plus (No Ethernet)
From: Wolfgang Denk @ 2011-02-06 21:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <A51EDB6E-A8AA-488A-B093-FED03DFC90DB@edesigns.dk>
Dear =?iso-8859-1?Q?Ronni_H=F8mpler?=,
In message <A51EDB6E-A8AA-488A-B093-FED03DFC90DB@edesigns.dk> you wrote:
>
> First off im sorry if this ends up the wrong place.
This is the perfectly right place...
...but U-Boot 1.1.3 is so old that you will not find many people here
that still remember.
I recommend to update and use somewhat current code instead.
Use v2010.09 (i. e. a version before the great earthquake).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I perceive a possibility of an immediate chronological sequence of
events which includes a violence.
- Terry Pratchett, _The Dark Side of the Sun_
^ permalink raw reply
* Re: [PATCH v2 2/3] sdhci-pci : Enable runtime PM support
From: Chris Ball @ 2011-02-06 21:15 UTC (permalink / raw)
To: Pierre Tardy; +Cc: linux-pm, linux-mmc, linux-kernel, Yunpeng Gao
In-Reply-To: <6722fa7986194808f4d69a1e5ba6d3f163b77da9.1297014479.git.pierre.tardy@intel.com>
Hi,
On Sun, Feb 06, 2011 at 07:02:49PM +0100, Pierre Tardy wrote:
> From: Yunpeng Gao <yunpeng.gao@intel.com>
>
> Follow the kernel runtime PM framework, enable runtime PM support of the
> sdhci host controller with pci interface.
>
> Note that this patch implements runtime_pm but now actually detects
> activity.
> It relies on higher level (childrens) to do actual waking up
> Activity detection is put in following patch
>
> Original version from: Yunpeng Gao <yunpeng.gao@intel.com>
> with modifications by: Pierre Tardy <pierre.tardy@intel.com>
>
> Signed-off-by: Pierre Tardy <pierre.tardy@intel.com>
I had to add a:
diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index 22581a1..48061b3 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -18,6 +18,7 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/device.h>
+#include <linux/pm_runtime.h>
#include <linux/mmc/host.h>
to prevent a compile error.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply related
* Re: [PATCH v2 2/3] sdhci-pci : Enable runtime PM support
From: Chris Ball @ 2011-02-06 21:15 UTC (permalink / raw)
To: Pierre Tardy; +Cc: linux-pm, linux-mmc, linux-kernel, Yunpeng Gao
In-Reply-To: <6722fa7986194808f4d69a1e5ba6d3f163b77da9.1297014479.git.pierre.tardy@intel.com>
Hi,
On Sun, Feb 06, 2011 at 07:02:49PM +0100, Pierre Tardy wrote:
> From: Yunpeng Gao <yunpeng.gao@intel.com>
>
> Follow the kernel runtime PM framework, enable runtime PM support of the
> sdhci host controller with pci interface.
>
> Note that this patch implements runtime_pm but now actually detects
> activity.
> It relies on higher level (childrens) to do actual waking up
> Activity detection is put in following patch
>
> Original version from: Yunpeng Gao <yunpeng.gao@intel.com>
> with modifications by: Pierre Tardy <pierre.tardy@intel.com>
>
> Signed-off-by: Pierre Tardy <pierre.tardy@intel.com>
I had to add a:
diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index 22581a1..48061b3 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -18,6 +18,7 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/device.h>
+#include <linux/pm_runtime.h>
#include <linux/mmc/host.h>
to prevent a compile error.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply related
* Re: Numonyx NOR and chip->mutex bug?
From: Michael Cashwell @ 2011-02-06 21:13 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linux-mtd, Holger brunck, stefan.bigler
In-Reply-To: <OFE5450B1B.EA07E31D-ONC125782F.005D4D25-C125782F.00601FE6@transmode.se>
On Feb 6, 2011, at 12:29 PM, Joakim Tjernlund wrote:
> Michael Cashwell <mboards@prograde.net> wrote on 2011/02/06 16:49:53:
>
>> That's clearly what's happening in Stefan's trace when thread 465 writes 0xe8 and the next write is 0x70 by thread 209. Such a sequence is absolutely illegal (for the flash) and the latter thread is the problem. If we could get a stack trace for that map_write 0x70 I think we'd find the thread awoke and touched the chip without verifying the state first. The question is why.
>
> Without my patch it is clear that you do end up with this problem. The first time one enter the for(;;) loop the driver reads out status from the chip before checking chip->state. This of course assumes that dropping the lock earlier may cause a schedule. So far Stefans tests indicates this to be true.
Yes, it was your patch and his log that lead me down that path!
>> One last idea.
>>
>> The whole for(;;) loop in inval_cache_and_wait_for_operation() looks odd to me. Continuing with your idea of moving the chip->state while loop first, I see other problems. It seems to me that anywhere we drop and retake the chip mutex the very next thing needs to be the state check loop. Any break in holding that mutex means we must go back to the top and check state again.
>>
>> I don't think the code as written does that. I have a completely reordered version of this function. (It didn't fix my issue but I think mine is something else.) On Monday I'll send that to you so you can consider it.
>
> Yes, it is a bit odd. In addition to my patch one could move the erase suspend tests before the if(!timeo) test.
Precisely. I suspect you may well already have my reordered version. :-)
>>> Oh, one more thing, possibly one needs to add cpu_relax() or similar to force gcc to reload chip->state in the while loop?
>>
>> I was also wondering about possible gcc optimization issues. I'm on 4.5.2 and that worked for me with the 2003 flash part. The same binaries fail with the 2008 parts, so, I don't know.
>
> Very recent gcc, I am 3.4.6 but recently I began testing a little with 4.5.2. I do think I will wait for 4.5.3
I tried 4.5.1 but it failed for other reasons. I submitted bug reports to gnu and a fix appeared (finally) in 4.5.2. It's been good so far but I'm always mindful of that issue.
Staying current is a two edge sword. In general, later gccs have better code analysis and warnings which are valuable even if we ship using an older version.
>> Keep in mind that chip->state is not a hardware access. It's just another struct member. And I think that the rules are that any function call counts as a sequence point and gcc isn't allowed to think it knows what the result is and must reload it.
>>
>> Lastly, consider the direction of the behavior. If we're in the state-check while loop then we got there because the two things were NOT equal. If an optimization error is causing a stale value to be compared wouldn't the observed behavior be that it remains not equal? (If it's not reloaded then how could it change?)
>>
>> I'd expect an optimization error like that to get us stuck in the while loop, not exit from it prematurely.
>
> Yes, all true. I wonder though if the mutex lock/unlock counts as a reload point? These are usually some inline asm. If not one could possibly argue that the first chip->state access, before entering the while body is using an old value.
Yes, how inlines interact with sequence points has never been entirely clear to me. Especially since the compiler is free to inline something I didn't tell it to and to ignore me telling to inline if it wants to.
I *think* the rules are semantic. If it's written (preprocessor aside) to look like a function call then it counts as a sequence point even if it ends up being inlined. But that's all quite beyond anything I can say for sure!
>> Makes me head hurt!
>
> You are not alone :)
So collectively maybe we can make it hurt less. That's my theory, anyway, and I'm sticking to it.
-Mike
^ permalink raw reply
* [patch 3/3] xtensa: Use generic IRQ Kconfig and set GENERIC_HARDIRQS_NO_DEPRECATED
From: Thomas Gleixner @ 2011-02-06 21:12 UTC (permalink / raw)
To: LKML; +Cc: Chris Zankel
In-Reply-To: <20110206211051.865188529@linutronix.de>
[-- Attachment #1: xtensa-set-nodepr.patch --]
[-- Type: text/plain, Size: 795 bytes --]
All chips converted.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/xtensa/Kconfig | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux-next/arch/xtensa/Kconfig
===================================================================
--- linux-next.orig/arch/xtensa/Kconfig
+++ linux-next/arch/xtensa/Kconfig
@@ -7,6 +7,8 @@ config ZONE_DMA
config XTENSA
def_bool y
select HAVE_IDE
+ select HAVE_GENERIC_HARDIRQS
+ select GENERIC_HARDIRQS_NO_DEPRECATED
help
Xtensa processors are 32-bit RISC machines designed by Tensilica
primarily for embedded systems. These processors are both
@@ -24,9 +26,6 @@ config GENERIC_FIND_NEXT_BIT
config GENERIC_HWEIGHT
def_bool y
-config GENERIC_HARDIRQS
- def_bool y
-
config GENERIC_GPIO
def_bool y
^ permalink raw reply
* [patch 2/3] xtensa: Convert s6000 gpio irq_chip to new functions
From: Thomas Gleixner @ 2011-02-06 21:12 UTC (permalink / raw)
To: LKML; +Cc: Chris Zankel
In-Reply-To: <20110206211051.865188529@linutronix.de>
[-- Attachment #1: xtensa-convert-s6000-gpio.patch --]
[-- Type: text/plain, Size: 2580 bytes --]
Also use proper wrappers for irq_desc access.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/xtensa/variants/s6000/gpio.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
Index: linux-next/arch/xtensa/variants/s6000/gpio.c
===================================================================
--- linux-next.orig/arch/xtensa/variants/s6000/gpio.c
+++ linux-next/arch/xtensa/variants/s6000/gpio.c
@@ -85,30 +85,29 @@ int s6_gpio_init(u32 afsel)
return gpiochip_add(&gpiochip);
}
-static void ack(unsigned int irq)
+static void ack(struct irq_data *d)
{
- writeb(1 << (irq - IRQ_BASE), S6_REG_GPIO + S6_GPIO_IC);
+ writeb(1 << (d->irq - IRQ_BASE), S6_REG_GPIO + S6_GPIO_IC);
}
-static void mask(unsigned int irq)
+static void mask(struct irq_data *d)
{
u8 r = readb(S6_REG_GPIO + S6_GPIO_IE);
- r &= ~(1 << (irq - IRQ_BASE));
+ r &= ~(1 << (d->irq - IRQ_BASE));
writeb(r, S6_REG_GPIO + S6_GPIO_IE);
}
-static void unmask(unsigned int irq)
+static void unmask(struct irq_data *d)
{
u8 m = readb(S6_REG_GPIO + S6_GPIO_IE);
- m |= 1 << (irq - IRQ_BASE);
+ m |= 1 << (d->irq - IRQ_BASE);
writeb(m, S6_REG_GPIO + S6_GPIO_IE);
}
-static int set_type(unsigned int irq, unsigned int type)
+static int set_type(struct irq_data *d, unsigned int type)
{
- const u8 m = 1 << (irq - IRQ_BASE);
+ const u8 m = 1 << (d->irq - IRQ_BASE);
irq_flow_handler_t handler;
- struct irq_desc *desc;
u8 reg;
if (type == IRQ_TYPE_PROBE) {
@@ -129,8 +128,7 @@ static int set_type(unsigned int irq, un
handler = handle_edge_irq;
}
writeb(reg, S6_REG_GPIO + S6_GPIO_BANK(0) + S6_GPIO_IS);
- desc = irq_to_desc(irq);
- desc->handle_irq = handler;
+ __set_irq_handler_unlocked(irq, handler);
reg = readb(S6_REG_GPIO + S6_GPIO_BANK(0) + S6_GPIO_IEV);
if (type & (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING))
@@ -160,12 +158,13 @@ static u8 demux_masks[4];
static void demux_irqs(unsigned int irq, struct irq_desc *desc)
{
+ struct irq_chip *chip = get_irq_desc_chip(desc);
u8 *mask = get_irq_desc_data(desc);
u8 pending;
int cirq;
- desc->chip->mask(irq);
- desc->chip->ack(irq);
+ chip->mask(&desc->irq_data);
+ chip->ack(&desc->irq_data));
pending = readb(S6_REG_GPIO + S6_GPIO_BANK(0) + S6_GPIO_MIS) & *mask;
cirq = IRQ_BASE - 1;
while (pending) {
@@ -174,7 +173,7 @@ static void demux_irqs(unsigned int irq,
pending >>= n;
generic_handle_irq(cirq);
}
- desc->chip->unmask(irq);
+ chip->unmask(&desc->irq_data));
}
extern const signed char *platform_irq_mappings[XTENSA_NR_IRQS];
^ permalink raw reply
* [patch 1/3] xtensa: Convert main irq_chip to new functions
From: Thomas Gleixner @ 2011-02-06 21:12 UTC (permalink / raw)
To: LKML; +Cc: Chris Zankel
In-Reply-To: <20110206211051.865188529@linutronix.de>
[-- Attachment #1: xtensa-convert-irq-chip.patch --]
[-- Type: text/plain, Size: 2625 bytes --]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
arch/xtensa/kernel/irq.c | 43 +++++++++++++++++++++----------------------
1 file changed, 21 insertions(+), 22 deletions(-)
Index: linux-next/arch/xtensa/kernel/irq.c
===================================================================
--- linux-next.orig/arch/xtensa/kernel/irq.c
+++ linux-next/arch/xtensa/kernel/irq.c
@@ -35,7 +35,6 @@ atomic_t irq_err_count;
asmlinkage void do_IRQ(int irq, struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
- struct irq_desc *desc = irq_desc + irq;
if (irq >= NR_IRQS) {
printk(KERN_EMERG "%s: cannot handle IRQ %d\n",
@@ -57,7 +56,7 @@ asmlinkage void do_IRQ(int irq, struct p
sp - sizeof(struct thread_info));
}
#endif
- desc->handle_irq(irq, desc);
+ generic_handle_irq(irq);
irq_exit();
set_irq_regs(old_regs);
@@ -111,50 +110,50 @@ skip:
return 0;
}
-static void xtensa_irq_mask(unsigned int irq)
+static void xtensa_irq_mask(struct irq_chip *d)
{
- cached_irq_mask &= ~(1 << irq);
+ cached_irq_mask &= ~(1 << d->irq);
set_sr (cached_irq_mask, INTENABLE);
}
-static void xtensa_irq_unmask(unsigned int irq)
+static void xtensa_irq_unmask(struct irq_chip *d)
{
- cached_irq_mask |= 1 << irq;
+ cached_irq_mask |= 1 << d->irq;
set_sr (cached_irq_mask, INTENABLE);
}
-static void xtensa_irq_enable(unsigned int irq)
+static void xtensa_irq_enable(struct irq_chip *d)
{
- variant_irq_enable(irq);
- xtensa_irq_unmask(irq);
+ variant_irq_enable(d->irq);
+ xtensa_irq_unmask(d->irq);
}
-static void xtensa_irq_disable(unsigned int irq)
+static void xtensa_irq_disable(struct irq_chip *d)
{
- xtensa_irq_mask(irq);
- variant_irq_disable(irq);
+ xtensa_irq_mask(d->irq);
+ variant_irq_disable(d->irq);
}
-static void xtensa_irq_ack(unsigned int irq)
+static void xtensa_irq_ack(struct irq_chip *d)
{
- set_sr(1 << irq, INTCLEAR);
+ set_sr(1 << d->irq, INTCLEAR);
}
-static int xtensa_irq_retrigger(unsigned int irq)
+static int xtensa_irq_retrigger(struct irq_chip *d)
{
- set_sr (1 << irq, INTSET);
+ set_sr (1 << d->irq, INTSET);
return 1;
}
static struct irq_chip xtensa_irq_chip = {
.name = "xtensa",
- .enable = xtensa_irq_enable,
- .disable = xtensa_irq_disable,
- .mask = xtensa_irq_mask,
- .unmask = xtensa_irq_unmask,
- .ack = xtensa_irq_ack,
- .retrigger = xtensa_irq_retrigger,
+ .irq_enable = xtensa_irq_enable,
+ .irq_disable = xtensa_irq_disable,
+ .irq_mask = xtensa_irq_mask,
+ .irq_unmask = xtensa_irq_unmask,
+ .irq_ack = xtensa_irq_ack,
+ .irq_retrigger = xtensa_irq_retrigger,
};
void __init init_IRQ(void)
^ permalink raw reply
* [patch 0/3] xtensa: Convert to new irq_chip functions
From: Thomas Gleixner @ 2011-02-06 21:12 UTC (permalink / raw)
To: LKML; +Cc: Chris Zankel
The following series converts xtensa to the new irq_chip functions and
sets GENERIC_HARDIRQS_NO_DEPRECATED
Thanks,
tglx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.