- 24 2月, 2008 34 次提交
-
-
由 Auke Kok 提交于
This counter is valuable to determine if the system is unable to timely return buffers to the hardware and this counter starts to increase well before the hardware starts to drop packets. If users experience rx_no_buffer_count increasing, they should increase the amount of descriptors. That will provide more buffers for the hardware and will decrease the chance of hard drops. Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Atsushi Nemoto 提交于
Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by conversion to generic PHY layer in kernel 2.6.23. Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Stephen Hemminger 提交于
Fix problems in LED management, so ethtool -p works correctly on Yukon-EC and other chips. The driver was incorrectly setting the PHY LED overide bits. Moral: read the spec sheet, not the vendor driver. Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Laura Garcia 提交于
Use register offset definition for WOLcgClr, rather than a magic number. This patch does not change the driver behaviour. Signed-off-by: NLaura Garcia Liebana <nevola@gmail.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Adrian Bunk 提交于
This patch fixes a check-after-use spotted by the Coverity checker. Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Bill Hayes 提交于
This patch eliminates a kernel panic with the igb driver in 2.6.25-rc2 when running on a Intel 82575 Ethernet controller with a 1000BASE-SX PHY. The panic does not happen with the 1000BASE-T PHY, only with a SX connection. Signed-off-by: NBill Hayes <bill.hayes@hp.com> Signed-off-by: NAndy Gospodarek <andy@greyhouse.net> Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Becky Bruce 提交于
Change all dma op invocations in gianfar.c to actually pass in the device pointer. Currently, the value is ignored, but it will be used going forward as we implement archdata for 32-bit powerpc. Signed-off-by: NBecky Bruce <becky.bruce@freescale.com> Acked-by: NAndy Fleming <afleming@freescale.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Francois Romieu 提交于
Reading a serie of zero from the cmos sram area do not work well with is_valid_ether_addr(). Let's read the mac address from the eeprom first as it seems more reliable. Fix for http://bugzilla.kernel.org/show_bug.cgi?id=9831Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Harvey Harrison 提交于
The forward declarations were already marked static, make the definitions be static as well. Fixes the sparse warnings as well. drivers/net/tlan.c:1403:5: warning: symbol 'TLan_HandleInvalid' was not declared. Should it be static? drivers/net/tlan.c:1435:5: warning: symbol 'TLan_HandleTxEOF' was not declared. Should it be static? drivers/net/tlan.c:1521:5: warning: symbol 'TLan_HandleStatOverflow' was not declared. Should it be static? drivers/net/tlan.c:1557:5: warning: symbol 'TLan_HandleRxEOF' was not declared. Should it be static? drivers/net/tlan.c:1692:5: warning: symbol 'TLan_HandleDummy' was not declared. Should it be static? drivers/net/tlan.c:1722:5: warning: symbol 'TLan_HandleTxEOC' was not declared. Should it be static? drivers/net/tlan.c:1770:5: warning: symbol 'TLan_HandleStatusCheck' was not declared. Should it be static? drivers/net/tlan.c:1845:5: warning: symbol 'TLan_HandleRxEOC' was not declared. Should it be static? drivers/net/tlan.c:1905:6: warning: symbol 'TLan_Timer' was not declared. Should it be static? drivers/net/tlan.c:1986:6: warning: symbol 'TLan_ResetLists' was not declared. Should it be static? drivers/net/tlan.c:2046:6: warning: symbol 'TLan_FreeLists' was not declared. Should it be static? drivers/net/tlan.c:2095:6: warning: symbol 'TLan_PrintDio' was not declared. Should it be static? drivers/net/tlan.c:2130:6: warning: symbol 'TLan_PrintList' was not declared. Should it be static? drivers/net/tlan.c:2166:6: warning: symbol 'TLan_ReadAndClearStats' was not declared. Should it be static? drivers/net/tlan.c:2242:1: warning: symbol 'TLan_ResetAdapter' was not declared. Should it be static? drivers/net/tlan.c:2328:1: warning: symbol 'TLan_FinishReset' was not declared. Should it be static? drivers/net/tlan.c:2451:6: warning: symbol 'TLan_SetMac' was not declared. Should it be static? drivers/net/tlan.c:2493:6: warning: symbol 'TLan_PhyPrint' was not declared. Should it be static? drivers/net/tlan.c:2542:6: warning: symbol 'TLan_PhyDetect' was not declared. Should it be static? drivers/net/tlan.c:2589:6: warning: symbol 'TLan_PhyPowerDown' was not declared. Should it be static? drivers/net/tlan.c:2614:6: warning: symbol 'TLan_PhyPowerUp' was not declared. Should it be static? drivers/net/tlan.c:2635:6: warning: symbol 'TLan_PhyReset' was not declared. Should it be static? drivers/net/tlan.c:2663:6: warning: symbol 'TLan_PhyStartLink' was not declared. Should it be static? drivers/net/tlan.c:2750:6: warning: symbol 'TLan_PhyFinishAutoNeg' was not declared. Should it be static? drivers/net/tlan.c:2906:5: warning: symbol 'TLan_MiiReadReg' was not declared. Should it be static? drivers/net/tlan.c:2996:6: warning: symbol 'TLan_MiiSendData' was not declared. Should it be static? drivers/net/tlan.c:3038:6: warning: symbol 'TLan_MiiSync' was not declared. Should it be static? drivers/net/tlan.c:3077:6: warning: symbol 'TLan_MiiWriteReg' was not declared. Should it be static? drivers/net/tlan.c:3147:6: warning: symbol 'TLan_EeSendStart' was not declared. Should it be static? drivers/net/tlan.c:3187:5: warning: symbol 'TLan_EeSendByte' was not declared. Should it be static? drivers/net/tlan.c:3248:6: warning: symbol 'TLan_EeReceiveByte' was not declared. Should it be static? drivers/net/tlan.c:3306:5: warning: symbol 'TLan_EeReadByte' was not declared. Should it be static? Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Julia Lawall 提交于
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) / (d)) but is perhaps more readable. Signed-off-by: NUrsula Braun <braunu@de.ibm.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Komuro 提交于
* If ConfigBase is 0x03c0 && manfid is (0x0149,0xc1ab), printk "use axnet_cs instead" message. Actually, most of the card with manfid(0x0149, 0xc1ab) use pcnet_cs driver. * remove entry (0x021b, 0x0202) Signed-off-by: NKomuro <komurojun-mbn@nifty.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Leonardo Potenza 提交于
Suppress the warning message about the 'netcard_portlist' defined but not used. Signed-off-by: NLeonardo Potenza <lpotenza@inwind.it> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Christian Borntraeger 提交于
Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Grant Grundler 提交于
Patch fixes: http://bugzilla.kernel.org/show_bug.cgi?id=5839 Init sequence needs to poll phy until phy reset is complete. This is the same problem that I fixed in 2002 in tulip driver. Thanks to manty@manty.net for testing this patch. Thanks to Pozsar Balazs <pozsy@uhulinux.hu> for posting/testing a similar patch before: http://lkml.org/lkml/2006/8/21/45Signed-off-by: NGrant Grundler <grundler@parisc-linux.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Andy Gospodarek 提交于
I booted an igb kernel with the option pci=nomsi and instantly noticed that interrupts no longer worked on my igb device. I took a look at the interrupt initialization and quickly discovered a comment stating: "DO NOT USE EIAME or IAME in legacy mode" It seemed a bit odd that bits to enable IAM were being set in legacy interrupt mode, so I dropped out the following parts and interrupts began working fine again. [Updated code flow and a nitpick spelling error --Auke] Signed-off-by: NAndy Gospodarek <andy@greyhouse.net> Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Scott Wood 提交于
The lock acquisition in fs_ioctl() does not appear to actually be necessary, and thus is simply removed. Signed-off-by: NScott Wood <scottwood@freescale.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Thomas Klein 提交于
This patch adds kdump support to the ehea driver. As the firmware doesn't free resource handles automatically, the driver has to run an as simple as possible free resource function in case of a crash shutdown. The function iterates over two arrays freeing all resource handles which are stored there. The arrays are kept up-to-date during normal runtime. The crash handler fn is triggered by the recently introduced PPC crash shutdown reg/unreg functions. Signed-off-by: NThomas Klein <tklein@de.ibm.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Mirco Tischler 提交于
This fixes the following compile error caused by commit 3a2d5b70 ("PM: Introduce PM_EVENT_HIBERNATE callback state") CC [M] drivers/usb/host/u132-hcd.o drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’: drivers/usb/host/u132-hcd.c:3224: error: expected expression before ‘int’ drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use in this function) ... Signed-off-by: NMirco Tischler <mt-ml@gmx.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Stephen Hemminger 提交于
When asked to blink LEDs the tg3 driver behaves when using: ethtool -p ethX The default value for data is zero, and other drivers interpret this as blink forever (or at least a really long time). The tg3 driver interprets this as blink once. All drivers should have the same behaviour. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Acked-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Oliver Pinter 提交于
Signed-off-by: NOliver Pinter <oliver.pntr@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Michael Chan 提交于
Because of some board issues, we need to disable parallel detect on an HP blade. Without this patch, the link state can become stuck when it goes into parallel detect mode. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
The previous patches to workaround the 5706S on an HP blade were not sufficient. The link state still does not change properly in some cases. This patch adds polling to make it completely reliable. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jeff Garzik 提交于
- Fix build 'make randconfig' build warning spotted by Toralf Foerster: drivers/scsi/mvsas.c: In function 'mvs_hexdump': drivers/scsi/mvsas.c:715: error: implicit declaration of function 'isalnum' - Remove unneeded prototypes (spotted by hch) Signed-off-by: NJeff Garzik <jgarzik@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jean Delvare 提交于
Adding the same item to a given linked list more than once is guaranteed to break and corrupt the list. This is however what we do in dmi_scan since commit 79da4721 ("x86: fix DMI out of memory problems"). Given that there is absolutely no interest in saving empty OEM strings anyway, I propose the simple and efficient fix below: we discard the empty OEM strings altogether. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NParag Warudkar <parag.warudkar@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Sergio Luis 提交于
Fix following warnings: WARNING: drivers/video/built-in.o(.text+0x7c64a): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c65d): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c679): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c699): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/video/built-in.o(.text+0x7c69f): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa3676): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa3689): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa36a5): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa36c5): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: drivers/built-in.o(.text+0xa36cb): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a079a): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a07ad): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a07c9): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a07e9): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan WARNING: vmlinux.o(.text+0x4a07ef): Section mismatch in reference from the function param_set_scroll() to the variable .devinit.data:ypan Remove __devinitdata annotation from the variable ypan. Signed-off-by: NSergio Luis <sergio@larces.uece.br> Cc: Michal Januszewski <spock@gentoo.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Paul Clements 提交于
NBD doesn't work well with CFQ (or AS) schedulers, so let's default to something else. The two problems I have experienced with nbd and cfq are: 1) nbd hangs with cfq on RHEL 5 (2.6.18) -- this may well have been fixed There's a similar debian bug that has been filed as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447638 There have been posts to nbd-general mailing list about problems with cfq and nbd also. 2) nbd performs about 10% better (the last time I tested) with deadline vs. cfq (the overhead of cfq doesn't provide much advantage to nbd [not being a real disk], and you end up going through the I/O scheduler on the nbd server anyway, so it makes sense that deadline is better with nbd) Signed-off-by: NPaul Clements <paul.clements@steeleye.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jean Delvare 提交于
Now that we gather on-board devices from both DMI types 10 and 41, there is a possibility that we list the same device twice. In order to not confuse drivers, and also to save memory, make sure that we do not add duplicate devices to the dmi_devices list. Signed-off-by: NJean Delvare <khali@linux-fr.org> Cc: Wim Van Sebroeck <wim@iguana.be> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David Brownell 提交于
For the "cmos" RTC, have /proc/driver/rtc say whether HPET based IRQ emulation is in effect. Given the problems we've had with this particular hardware maldesign (and the fact that most BIOS code seems not to provide the IRQ routing needed to use the saner HPET modes), this should help troubleshooting. Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ned Forrester 提交于
Fixes a sequencing bug in spi driver pxa2xx_spi.c in which the chip select for a transfer may be asserted before the clock polarity is set on the interface. As a result of this bug, the clock signal may have the wrong polarity at transfer start, so it may need to make an extra half transition before the intended clock/data signals begin. (This probably means all transfers are one bit out of sequence.) This only occurs on the first transfer following a change in clock polarity in systems using more than one more than one such polarity. The fix assures that the clock mode is properly set before asserting chip select. This bug was introduced in a patch merged on 2006/12/10, kernel 2.6.20. The patch defines an additional bit in: include/asm-arm/arch-pxa/regs-ssp.h for 2.6.25 and newer kernels but this addition must be made in: include/asm-arm/arch-pxa/pxa-regs.h for kernels between 2.6.20 and 2.6.24, inclusive Signed-off-by: NNed Forrester <nforrester@whoi.edu> Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Cc: Russell King <rmk@arm.linux.org.uk> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Atsushi Nemoto 提交于
The atmel_spi driver does not initialize clock polarity correctly (except for at91rm9200 CS0 channel) in some case. The atmel_spi driver uses gpio-controlled chipselect. OTOH spi clock signal is controlled by CSRn.CPOL bit, but this register controls clock signal correctly only in 'real transfer' duration. At the time of cs_activate() call, CSRn.CPOL will be initialized correctly, but the controller do not know which channel is to be used next, so clock signal will stay at the inactive state of last transfer. If clock polarity of new transfer and last transfer was differ, new transfer will start with wrong clock signal state. For example, if you started SPI MODE 2 or 3 transfer after SPI MODE 0 or 1 transfer, the clock signal state at the assertion of chipselect will be low. Of course this will violates SPI transfer. This patch is short term solution for this problem. It makes all CSRn.CPOL match for the transfer before activating chipselect. For longer term, the best fix might be to let NPCS0 stay selected permanently in MR and overwrite CSR0 with to the new slave's settings before asserting CS. Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp> Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Haavard Skinnemoen 提交于
We should only return IRQ_HANDLED when we actually found something to handle. This is important since the USART interrupt handler may be shared with the timer interrupt on some chips. Pointed-out-by: Nmichael <trimarchi@gandalf.sssup.it> Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 mark gross 提交于
The following is a clean up and correction of the copyright holding entities for the files associated with the intel iommu code. Signed-off-by: <mgross@linux.intel.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Rafael J. Wysocki 提交于
During the last step of hibernation in the "platform" mode (with the help of ACPI) we use the suspend code, including the devices' ->suspend() methods, to prepare the system for entering the ACPI S4 system sleep state. But at least for some devices the operations performed by the ->suspend() callback in that case must be different from its operations during regular suspend. For this reason, introduce the new PM event type PM_EVENT_HIBERNATE and pass it to the device drivers' ->suspend() methods during the last phase of hibernation, so that they can distinguish this case and handle it as appropriate. Modify the drivers that handle PM_EVENT_SUSPEND in a special way and need to handle PM_EVENT_HIBERNATE in the same way. These changes are necessary to fix a hibernation regression related to the i915 driver (ref. http://lkml.org/lkml/2008/2/22/488). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@ucw.cz> Tested-by: NJeff Chua <jeff.chua.linux@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 2月, 2008 6 次提交
-
-
由 Adrian Bunk 提交于
In current mainline, __devinit qpti_sbus_probe() still is calling __init qpti_chain_add(). Change occurrences of __init to __devinit to fix. Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Ke Wei 提交于
Convert rough draft Marvell 6440 driver to a working driver. Added support for SAS and SATA devices, hotplug, wide port, and expanders. Signed-off-by: NKe Wei <kewei@marvell.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Jeff Garzik 提交于
Signed-off-by: NJeff Garzik <jgarzik@redhat.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Jesse Barnes 提交于
Make sure the restoration correctly restores the AR registers by flipping the ARX register into index mode before doing anything. Without this, some people have had the text mode restore all green. Signed-off-by: NJesse Barnes <jesse.barnes@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 James Bottomley 提交于
The current sas_scsi_clear_queue_lu() is wrongly checking for commands which match the pointer to the one passed in. It should be checking for commands which are on the same logical unit as the one passed in. Fix this by checking target pointer and LUN for equality. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 James Bottomley 提交于
The clear nexus I_T and clear nexus I_T_L functions in the aic94xx specify the SUSPEND_TX flag which causes the sequencer to be suspended until it receives a RESUME_TX. Unfortunately, nothing ever sends the resume, so the sequencer on the link is stopped forever, leading to eventual timeouts and I/O errors. Since clear nexus commands are only executed as part of error recovery, it's perfectly fine to keep the sequencer running on the link ... as soon as the recovery function is completed, we'll send it the commands to retry. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-