net: Fix incorrect DHCP/BOOTP packets on 64-bit systems
This commit fixes incorrect DHCP/BOOTP packet layout caused by
'ulong' type size difference on 64 and 32-bit architectures.
It also renames NetReadLong()/NetCopyLong() to
net_read_u32/net_copy_u32() accordingly.
Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
Joe Hershberger [Wed, 8 Apr 2015 06:41:06 +0000 (01:41 -0500)]
net: cosmetic: Fix var naming net <-> eth drivers
Update the naming convention used in the network stack functions and
variables that Ethernet drivers use to interact with it.
This cleans up the temporary hacks that were added to this interface
along with the DM support.
This patch has a few remaining checkpatch.pl failures that would be out
of the scope of this patch to fix (drivers that are in gross violation
of checkpatch.pl).
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
Joe Hershberger [Wed, 8 Apr 2015 06:41:01 +0000 (01:41 -0500)]
net: cosmetic: Change IPaddr_t to struct in_addr
This patch is simply clean-up to make the IPv4 type that is used match
what Linux uses. It also attempts to move all variables that are IP
addresses use good naming instead of CamelCase. No functional change.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
Masahiro Yamada [Tue, 31 Mar 2015 03:47:53 +0000 (12:47 +0900)]
dm: select CONFIG_DM* options
As mentioned in the previous commit, adding default values in each
Kconfig causes problems because it does not co-exist with the
"depends on" syntax. (Please note this is not a bug of Kconfig.)
We should not do so unless we have a special reason. Actually,
for CONFIG_DM*, we have no good reason to do so.
Generally, CONFIG_DM is not a user-configurable option. Once we
convert a driver into Driver Model, the board only works with Driver
Model, i.e. CONFIG_DM must be always enabled for that board.
So, using "select DM" is more suitable rather than allowing users to
modify it. Another good thing is, Kconfig warns unmet dependencies
for "select" syntax, so we easily notice bugs.
Actually, CONFIG_DM and other related options have been added
without consistency: some into arch/*/Kconfig, some into
board/*/Kconfig, and some into configs/*_defconfig.
This commit prefers "select" and cleans up the following issues.
[1] Never use "CONFIG_DM=n" in defconfig files
It is really rare to add "CONFIG_FOO=n" to disable CONFIG options.
It is more common to use "# CONFIG_FOO is not set". But here, we
do not even have to do it.
Less than half of OMAP3 boards have been converted to Driver Model.
Adding the default values to arch/arm/cpu/armv7/omap3/Kconfig is
weird. Instead, add "select DM" only to appropriate boards, which
eventually eliminates "CONFIG_DM=n", etc.
[2] Delete redundant CONFIGs
Sandbox sets CONFIG_DM in arch/sandbox/Kconfig and defines it again
in configs/sandbox_defconfig.
Likewise, OMAP3 sets CONFIG_DM arch/arm/cpu/armv7/omap3/Kconfig and
defines it also in omap3_beagle_defconfig and devkit8000_defconfig.
Masahiro Yamada [Tue, 31 Mar 2015 03:47:52 +0000 (12:47 +0900)]
dm: spi_flash: fix wrong dependency
CONFIG_SPI does not exist in Kconfig in the first place, so the
dependency "depends on DM && SPI" is never met, i.e., DM_SPI_FLASH
can never be enabled (unless you ignore the dependency in an illegal
way. See below.)
Actually, some defconfigs such as socfpga_*_defconfig define
CONFIG_DM_SPI_FLASH=y, but it never appears in the .config file
because of this wrong dependency.
On the other hand, all the Tegra boards enable DM_SPI_FLASH because
config DM_SPI_FLASH
default y
silently ignores the dependency.
Unfortunately, this style of CONFIG definition is abused everywhere
in U-Boot, so we easily miss such a wrong dependency.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
Simon Glass [Wed, 25 Mar 2015 18:22:49 +0000 (12:22 -0600)]
dm: usb: xhci: Use a function to get xhci_ctrl
Rather than getting this directly from struct usb_device, call a function
to obtain it. This will make it possible for driver model to provide it
another way.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:45 +0000 (12:22 -0600)]
dm: usb: tegra: Remove the port_addr_clear_csc variable
This variable is a bit of a hack. We can obtain the same information from
the normal device config. This will fit better with driver model, where
global variables are best avoided.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:43 +0000 (12:22 -0600)]
dm: usb: Add support for USB ethernet devices with driver model
Add support for scanning USB etghernet devices with driver model. This mostly
involves scanning all buses since device numbering is not unique across
buses.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:39 +0000 (12:22 -0600)]
dm: usb: sandbox: Add an emulator for USB flash devices
This emulator supports USB enumeration and allows a local file to be provided
as the contents of the emulated flash stick. U-Boot can then use the file as
it would a normal device, with all access passing through the usb_stor layer
and the USB stack.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:37 +0000 (12:22 -0600)]
dm: usb: sandbox: Add a uclass for USB device emulation
With sandbox we want to be able to emulate USB devices so that we can test
the USB stack. Add a uclass to support this. It implements the same
operations as a normal USB device driver, but in this case passes them on
to an emulation driver.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:34 +0000 (12:22 -0600)]
dm: usb: Support driver model with USB keyboards
Allow USB keyboards to work with driver model. The main difference is that
we can have multiple buses (each with its own device numbering) and each
bus must be scanned.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:32 +0000 (12:22 -0600)]
dm: usb: Allow setting up a USB controller as a device/gadget
Some controllers support OTG (on-the-go) where they can operate as either
host or device. The gadget layer in U-Boot supports this.
While this layer does not interact with driver model, we can provide a
function which sets up the controller in the correct way. This way the code
at least builds (although it likely will not work).
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:31 +0000 (12:22 -0600)]
dm: usb: Bind generic USB devices when there is no driver
At present USB devices with no driver model driver cannot be seen in the
device list, and we fail to set them up correctly. This means they cannot
be used.
While having real drivers that support driver model for all USB devices
is the eventual goal, we are not there yet.
As a stop-gap, add a generic USB driver which is bound when we do not have
a real driver. This allows the device to be set up and shown on the bus.
It also allows ad-hoc code (such as usb_ether) to find these devices and
set them up.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:30 +0000 (12:22 -0600)]
dm: usb: Allow USB drivers to be declared and auto-probed
USB devices in U-Boot are currently probed only after all devices have
been enumerated. Each type of device is probed by custom code, e.g.:
- USB storage
- Keyboard
- Ethernet
With driver model this approach doesn't work very well. We could build
a picture of the bus and then go back and add the devices later, but
this means that the data structures are incomplete for quite a while.
It also does not follow the model of being able to bind a device when we
discover it.
We would prefer to have devices automatically be bound as the device is
enumerated. This allows us to attach drivers to particular USB classes
or product/vendor IDs. This is the method used by Linux.
Add the required #defines from Linux, a way of declaring a USB driver and
the logic to locate the correct driver given the USB device's descriptors.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:27 +0000 (12:22 -0600)]
dm: usb: Drop the EHCI weak functions
These are a pain with driver model because we might have different EHCI
drivers which want to implement them differently. Now that they use
consistent function signatures, we can in good conscience move them to
a struct.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Fix non-driver-model EHCI to set up the EHCI operations correctly: Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 25 Mar 2015 18:22:26 +0000 (12:22 -0600)]
dm: usb: Refactor EHCI init
Move the bulk of the code in usb_lowlevel_init() into a separate function
which will also be used by driver model. Keep the CONFIG options out of
this function by providing a tweak flag for Faraday. We need to avoid using
CONFIG options in driver model code where possible, since it makes it
impossible to use multiple controllers in that code where they have
different options.
The CONFIG_EHCI_HCD_INIT_AFTER_RESET option is also kept out of the
common init function. With driver model the controller will be able to
perform this extra init itself after registering with the EHCI layer.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:25 +0000 (12:22 -0600)]
dm: usb: ehci: Use a function to find the controller from struct udevice
With driver model we want to remove the controller pointer in struct udevice
and use driver model data structures instead. To prepare for this, move
access to this field to a function which can provide a different
implementation for driver model.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:24 +0000 (12:22 -0600)]
dm: usb: Pass EHCI controller pointer to ehci_get_portsc_register()
Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller. This makes the weak functions
use a consistent API.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:23 +0000 (12:22 -0600)]
dm: usb: Pass EHCI controller pointer to ehci_set_usbmode()
Adjust this function so that it is passed an EHCI controller pointer so that
implementations can look up their controller. This makes the weak functions
use a consistent API.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:20 +0000 (12:22 -0600)]
dm: usb: tegra: Store the controller type explicitly
At present the tegra driver uses a separate pointer to know which controller
type is in use. This works because only one controller type is used at a
time.
With driver model we want to make the controller state hermetic in the sense
that it is not necessary to look elsewhere to know the controller type. This
will permit a controller to implement the EHCI weak functions without
reference to global data structures.
To achieve this, define an enum for the controller type and store it with
the information on each EHCI controller.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:19 +0000 (12:22 -0600)]
dm: usb: Allow ECHI to hold private data for the controller
Add a private data pointer that clients of EHCI can use to access their
private information. This establishes a link between struct ehci_ctrl and
its associated controller data structure.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:15 +0000 (12:22 -0600)]
dm: usb: Move storage device scanning into its own function
The usb_stor_scan() function is quite long, so split out the code that scans
each device into its own function. Also, rather than setting up the block
device list once at the start, set it up as each device is scanned. This
makes it possible to use this code from driver model.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 25 Mar 2015 18:22:07 +0000 (12:22 -0600)]
dm: usb: Complete the splitting up of usb_new_device()
This function now calls usb_setup_device() to set up the device and
usb_hub_probe() to check if it is a hub. The XHCI special case is now a
parameter to usb_setup_device(). The latter will be used by the USB uclass
when it is added, since it does not rely on any CONFIGs or legacy data
structures.
Signed-off-by: Simon Glass <sjg@chromium.org>
Bug-fixes for descriptor reading and usb_new_device() return value Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Marek Vasut <marex@denx.de> Tested-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 25 Mar 2015 18:22:05 +0000 (12:22 -0600)]
dm: usb: Move descriptor setup code into its own function
usb_new_device() is far too long and does far too much. As a first step, move
the code that does initial setup and reads a descriptor into its own function
called usb_setup_descriptor().
For XHCI the init order is different - we set up the device but don't
actually read the descriptor until after we set an address. Support this
option as a parameter to usb_setup_descriptor().
Avoid changing this torturous code more than necessary to make it easy to
review.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
projects / u-boot / log