u-boot.git/common/stdio.c, branch v2015.04 Unnamed repository; edit this file 'description' to name the repository. stdio: Fix memleak on stdio_deregister 2014-11-04T05:04:00+00:00 Hans de Goede hdegoede@redhat.com 2014-09-24T12:06:09+00:00 88274b6c431f48d44743fe4d007068bec63505ff stdio_register makes a malloc-ed copy of struct stdio_dev through stdio_clone, free the malloc-ed memory on stdio_deregister. Signed-off-by: Hans de Goede <hdegoede@redhat.com> 
stdio_register makes a malloc-ed copy of struct stdio_dev through stdio_clone,
free the malloc-ed memory on stdio_deregister.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
serial: make local functions static 2014-10-25T11:02:02+00:00 Jeroen Hofstee jeroen@myspectrum.nl 2014-10-08T20:57:44+00:00 654f8d0f3d4c606b75b70bbf0b1303a6074f0788 Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl> 
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
stdio: Add force parameter to stdio_deregister 2014-10-06T12:50:43+00:00 Hans de Goede hdegoede@redhat.com 2014-09-20T14:54:37+00:00 32d019265d1f0c334f2f86407abf295d46bd2f4d In some cases we really want to move forward with a deregister, add a force parameter to allow this, and replace the dev with a nulldev in this case. Signed-off-by: Hans de Goede <hdegoede@redhat.com> 
In some cases we really want to move forward with a deregister, add a force
parameter to allow this, and replace the dev with a nulldev in this case.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
dm: Make driver model available before board_init() 2014-09-10T18:59:58+00:00 Simon Glass sjg@chromium.org 2014-09-03T23:37:01+00:00 9fb02491fe96991cbedc49c7ebe5cdd271d1b6a7 For some boards board_init() will change GPIOs, so we need to have driver model available before then. Adjust the board init to arrange this, but enable it for driver model only, just to be safe. This does create additional #ifdef logic, but it is safer than trying to make a pervasive change which may cause some boards to break. Signed-off-by: Simon Glass <sjg@chromium.org> 
For some boards board_init() will change GPIOs, so we need to have driver
model available before then. Adjust the board init to arrange this, but
enable it for driver model only, just to be safe.

This does create additional #ifdef logic, but it is safer than trying to
make a pervasive change which may cause some boards to break.

Signed-off-by: Simon Glass <sjg@chromium.org>
stdio: Provide functions to add/remove devices using stdio_dev 2014-07-23T13:07:24+00:00 Simon Glass sjg@chromium.org 2014-07-23T12:55:05+00:00 d97143a67c696101b68eaaa3deb57ab36e288b77 The current functions for adding and removing devices require a device name. This is not convenient for driver model, which wants to store a pointer to the relevant device. Add new functions which provide this feature and adjust the old ones to call these. Signed-off-by: Simon Glass <sjg@chromium.org> 
The current functions for adding and removing devices require a device name.
This is not convenient for driver model, which wants to store a pointer to
the relevant device. Add new functions which provide this feature and adjust
the old ones to call these.

Signed-off-by: Simon Glass <sjg@chromium.org>
stdio: Pass device pointer to stdio methods 2014-07-23T13:07:23+00:00 Simon Glass sjg@chromium.org 2014-07-23T12:54:59+00:00 709ea543b92489e7729d2d7ddd6c9f451e52158c At present stdio device functions do not get any clue as to which stdio device is being acted on. Some implementations go to great lengths to work around this, such as defining a whole separate set of functions for each possible device. For driver model we need to associate a stdio_dev with a device. It doesn't seem possible to continue with this work-around approach. Instead, add a stdio_dev pointer to each of the stdio member functions. Note: The serial drivers have the same problem, but it is not strictly necessary to fix that to get driver model running. Also, if we convert serial over to driver model the problem will go away. Code size increases by 244 bytes for Thumb2 and 428 for PowerPC. 22: stdio: Pass device pointer to stdio methods arm: (for 2/2 boards) all +244.0 bss -4.0 text +248.0 powerpc: (for 1/1 boards) all +428.0 text +428.0 Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de> Reviewed-by: Marek Vasut <marex@denx.de> 
At present stdio device functions do not get any clue as to which stdio
device is being acted on. Some implementations go to great lengths to work
around this, such as defining a whole separate set of functions for each
possible device.

For driver model we need to associate a stdio_dev with a device. It doesn't
seem possible to continue with this work-around approach.

Instead, add a stdio_dev pointer to each of the stdio member functions.

Note: The serial drivers have the same problem, but it is not strictly
necessary to fix that to get driver model running. Also, if we convert
serial over to driver model the problem will go away.

Code size increases by 244 bytes for Thumb2 and 428 for PowerPC.

22: stdio: Pass device pointer to stdio methods
       arm: (for 2/2 boards)  all +244.0  bss -4.0  text +248.0
   powerpc: (for 1/1 boards)  all +428.0  text +428.0

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
serial: arm_dcc: Remove stdio structure support 2013-08-13T06:38:29+00:00 Jagannadha Sutradharudu Teki jagannadha.sutradharudu-teki@xilinx.com 2013-08-03T19:52:24+00:00 32749e91aa31338882c02d3499c1376e7e794b82 Removed stdio structure ops support on arm_dcc driver, and need to register with serial core so-that it can access like remianing serial drivers. Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> 
Removed stdio structure ops support on arm_dcc
driver, and need to register with serial core
so-that it can access like remianing serial drivers.

Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Merge branch 'master' of git://git.denx.de/u-boot-i2c 2013-07-24T13:50:24+00:00 Tom Rini trini@ti.com 2013-07-24T13:22:28+00:00 c2120fbfbc4d1f6953228f86be8bdbf38bacfdab The sandburst-specific i2c drivers have been deleted, conflict was just over the SPDX conversion. Conflicts: board/sandburst/common/ppc440gx_i2c.c board/sandburst/common/ppc440gx_i2c.h Signed-off-by: Tom Rini <trini@ti.com> 
The sandburst-specific i2c drivers have been deleted, conflict was just
over the SPDX conversion.

Conflicts:
	board/sandburst/common/ppc440gx_i2c.c
	board/sandburst/common/ppc440gx_i2c.h

Signed-off-by: Tom Rini <trini@ti.com>
Add GPL-2.0+ SPDX-License-Identifier to source files 2013-07-24T13:44:38+00:00 Wolfgang Denk wd@denx.de 2013-07-08T07:37:19+00:00 1a4596601fd395f3afb8f82f3f840c5e00bdd57a Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> 
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
i2c, soft-i2c: switch to new multibus/multiadapter support 2013-07-23T03:54:29+00:00 Heiko Schocher hs@denx.de 2013-01-29T07:53:15+00:00 ea818dbbcd59300b56014ac2d67798a54994eb9b - added to soft_i2c driver new multibus/multiadpater support - adapted all config files, which uses this driver Signed-off-by: Heiko Schocher <hs@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Stephen Warren <swarren@wwwdotorg.org> 
- added to soft_i2c driver new multibus/multiadpater support
- adapted all config files, which uses this driver

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>