1
0
Fork 0
Commit Graph

23 Commits (7c154711a6705bbc3036d8f64944e8882fe3fd84)

Author SHA1 Message Date
Viresh Kumar f3e6c0971a greybus: svc: Expose and retain VID/PID received from bootrom for ES2
ES2 chips doesn't have efuses for storing module's vendor_id and
product_id and so we have hacked bootrom earlier using firmware
protocol, so that VID/PID can be received for fetching firmware
packages.

Another requirement is to expose them to sysfs, so that modules can be
identified properly.

That can be easily solved by updating interface's VID/PID, when fetched
using firmware protocol and later reusing them while the module switches
its identity from bootrom to firmware.

Do that only if the module is ES2 and the VID/PID sent during hotplug
are both 0.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-22 15:24:58 -08:00
Johan Hovold 8eff510961 greybus: firmware: abort if AP_READY fails
Abort if the AP_READY request fails.

Also update the comment suggesting that this operation was a temporary
one.

Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-21 22:46:38 -08:00
Greg Kroah-Hartman eb8fafdfb9 greybus: firmware: log the name of the firmware being requested
People are getting confused as to what the firmware file name is for
their module, so log it to make it easier to find modules with "blank"
vid/pid values and let people know what to name their firmware files.

Because we are now logging this, turn the debug message after the
firmware request into an error message if something fails.

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reviewed-by: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-21 11:39:05 -08:00
Johan Hovold 3e1b8c753d greybus: firmware: remove skip-disconnected flag
Remove the legacy protocol flag that was used to suppress sending the
control disconnected operation.

Instead rely on the fact that no control operations will be sent by
core to an interface that has been removed (e.g. after having received a
new hotplug event after the bootrom has jumped to the new image).

Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-19 12:17:13 -08:00
Michael Scott b29906af20 greybus: firmware: replace colons with underscore in firmware file request
Due to some issues with handling colons in Android (and possibly
future exposure to other problems) we should remove the colons from
the firmware file request.  Replacing them with underscores.

Specifically, we copy firmware into the Android build using a line
similar to this:
PRODUCT_COPY_FILES += \
    source-repo/ara:00000126:00001000:00000001:00000001:02.tftf:system/etc/firmware/ara:00000126:00001000:00000001:00000001:02.tftf

There is a colon delimiter between the source and destination in the
PRODUCT_COPY_FILES format.  The greybus naming logic breaks the parsing
routine and generates an Android build break.

Signed-off-by: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-15 14:41:18 -08:00
Eli Sennesh fc41c2da44 greybus: firmware/bootrom: debug output from bootrom protocol
The bootrom protocol issues no dynamic debugging messages when it functions
successfully.  Use dev_dbg() to fix that by issuing kernel logs when firmware
download works.

Signed-off-by: Eli Sennesh <esennesh@leaflabs.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2016-01-09 00:44:20 -08:00
Eli Sennesh 3563ff88e6 greybus: firmware and svc: detect the difference between ES2 and ES3 chips
The Greybus SVC code needs to read and clear the module boot status upon
hotplug; this requires reading two different attributes depending on whether
we're running on ES2 or ES3.  On Marti Bolivar's (mbolivar@leaflabs.com)
advice, we detect ES2 using the unique ES2_DDBL1_MFR_ID and ES2_DDBL1_PROD_ID
for ES2 hardware, and treat all other chips as ES3 appropriately.  This patch
detects the difference and adds the appropriate definitions for ES3 hardware.

Signed-off-by: Eli Sennesh <esennesh@leaflabs.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-12-22 14:38:46 -08:00
Viresh Kumar b32a5c5346 greybus: interface: Prefix DDBL1 attributes with ddbl1_ instead of unipro_
The Device descriptor block Level 1 (DDBL1) attributes are specified by
the MIPI standard and prefixing them with 'unipro_' isn't the best thing
to do. They should be prefixed with DDBL1 instead.

To make it more readable/clear:
- rename macros and variable by prefixing them with ddbl1_.
- write full names for mfg and prod ids as manufacturer and product ids.
- replace mfg (manufacturing) with mfr (manufacturer)

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-12-22 13:00:52 -08:00
Viresh Kumar 2f3db927cd greybus: don't use %h and %hh for printing short and char variables
Because the width of our fields is already known, we can use %0Nx (for
hex) to print N bytes and %u (for unsigned decimal), instead of using %h
and %hh, which isn't that readable.

This patch makes following changes:
- s/%hx/%04x
- s/%04hx/%04x
- s/%hhx/%02x
- s/%02hhx/%02x
- s/%hhu/%u
- s/%hu/%u
- s/%x/%02x for u8 value (only at a single place)

Suggested-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-12-04 16:23:36 -08:00
Viresh Kumar f1e941a6e4 greybus: firmware: Fetch es2 VID/PID to distinguish module vendors
The es2 chip doesn't have VID/PID programmed into the hardware and we
need to hack that up to distinguish different modules and their firmware
packages.

This fetches VID/PID (over firmware protocol) for es2 chip only, when
VID/PID already sent during hotplug are 0.

Since only the bootrom contains a firmware protocol cport, this only
affects bootrom's working and not nuttx.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-11-30 08:19:12 -08:00
Johan Hovold 9f59263a89 greybus: interface: rename vendor and product attributes
Rename vendor and product attributes vendor_id and product_id.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-11-25 15:27:06 -08:00
Johan Hovold f65fa47f28 greybus: fix vendor and product matching
Fix vendor and product matching by matching on the 32-bit Ara vendor and
product ids.

Remove the "fake" 16-bit vendor and product ids and export the Ara ids
using the "vendor" and "product" interface attributes instead.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-11-21 17:15:35 -08:00
Johan Hovold 87f6c976f4 greybus: firmware: break long lines
Break lines longer than 80 cols, and clean up an error message while at
it.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-11-19 16:07:48 -08:00
Johan Hovold 98645a9c69 greybus: firmware: fix information leak
Add missing sanity checks on get_firmware-request offset and size
parameters to fix potential information leaks.

This prevents remotely controlled information leaks as the requestor
currently controls both the 32-bit firmware-image offset and the amount
of data that is returned (up to host-device MTU).

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-11-19 16:07:48 -08:00
Greg Kroah-Hartman 0a72bd36df greybus: firmware: use the bundle struct device instead of the connector
We are removing struct device from the gb_connection structure in the
near future.  The gb_bundle structure's struct device should be used as
a replacement.

This patch moves the firmware driver to use the bundle pointer instead
of the connection pointer.

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reviewed-by: Alex Elder <elder@linaro.org>
2015-10-15 09:19:15 -07:00
Viresh Kumar 336dfeaba1 greybus: firmware: Don't send control-disconnected event for firmware protocol
After downloading the firmware for the next boot stage, module's
firmware (for current boot stage) jumps into it and the new firmware and
sends hotplug request to SVC. On hotplug request from the SVC, the AP
first removes the existing interface.

At this time, there is no point sending disconnected event for the
firmware protocol, for the firmware used in previous stage, as the new
firmware wouldn't be aware about it.

Set flags for firmware protocol to skip control-disconnected operations.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-09-24 15:25:03 -07:00
Viresh Kumar 06986a2cbe greybus: firmware: drop 'stage' from ready-to-boot request
The spec says that it doesn't need it, so dropping it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-09-24 15:25:03 -07:00
Viresh Kumar 4c9e228407 greybus: firmware: Send AP-ready operation
Module's Bootrom needs a way to know (currently), when to start sending
requests to the AP. The version request is sent before connection_init()
routine is called, and if the module sends the request right after
receiving version request, the connection->private field will be NULL.

Fix this TEMPORARILY by sending an AP_READY request.

Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-09-14 21:52:16 -07:00
Viresh Kumar 1a8862863a greybus: firmware: firmware image name has .tftf instead of .fw
That's how the bootrom-tool names it, and that's how the kernel should
expect it.

Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-09-14 21:52:16 -07:00
Viresh Kumar c9733b78ca greybus: firmware: Fix incorrect firmware file's name
All the id-fields are 32 bit long instead of 16 bits and so we will need
8 characters per field instead of four. Also the stage field is only one
byte long and so needs just two characters to represent it.

Reported-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-09-14 21:52:16 -07:00
Viresh Kumar 8bcc2d80dd greybus: firmware: firmware's file name is 32 characters long
28 is the wrong value and should be 32 instead.

Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-09-14 21:52:16 -07:00
Johan Hovold af0b4d5a19 greybus: firmware: fix potential stack corruption
Use snprintf when generating the firmware name to avoid stack corruption
if the fixed-size buffer overflows.

Note that the current buffer size appears to expect 16-bit ids while
the they are actually 32-bit, something which could trigger the
corruption.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
2015-09-01 14:42:02 +02:00
Viresh Kumar 90f1b617d8 greybus: Add firmware protocol driver
This adds firmware protocol driver based on the latest specs available
on mailing lists. This uses the firmware framework present in kernel.

Refer Documentation/firmware_class/README on how it works.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-08-11 22:12:59 -07:00