mcpm: exynos: Fix races in exynos_power_up()

There were two problems in exynos_power_up():

1. We were setting the mcpm_entry_point _after_ we powered things up.
   If there was too long of a delay here it's possible that a CPU
   might come up and look at the old entry point.

2. We were relying on the mcpm_cluster_state taking a little while to
   take effect.  When deciding whether to adjust cci settings we were
   checking whether a cluster was currently down.  However, we really
   wanted to know whether the cluster was down at the start of the
   block of code and we were just getting lucky that our powering on
   of the cluster hadn't yet taken effect.

BUG=chrome-os-partner:26867
TEST=Sprinkle udelay(1000) calls in exynos_power_up() and see that
system boots OK and suspend/resumes OK.

Change-Id: If751c6a7f232295e736e9ba1b3f1379cb6d01b7c
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190316
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: <thomas.ab@samsung.com>
Commit-Queue: Wonjoon Lee <woojoo.lee@samsung.com>
(cherry picked from commit 5f9a5273611a34a6cba96677ac85504f4eb8d823)
Reviewed-on: https://chromium-review.googlesource.com/190459
UPSTREAM: coredump: add new %P variable in core_pattern

Add a new %P variable to be used in core_pattern.  This variable contains
the global PID (PID in the init namespace) as %p contains the PID in the
current namespace which isn't always what we want.

The main use for this is to make it easier to handle crashes that happened
within a container.  With that new variables it's possible to have the
crashes dumped into the container or forwarded to the host with the right
PID (from the host's point of view).

BUG=chromium:351568
TEST=`cbuildbot link-release` passes

Signed-off-by: Stphane Graber <stgraber@ubuntu.com>
Reported-by: Hans Feldt <hans.feldt@ericsson.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Andy Whitcroft <apw@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Mike Frysinger <vapier@chromium.org>
(cherry picked from commit 65aafb1e7484b7434a0c1d4c593191ebe5776a2f)

Change-Id: I3521e781c226c9fb73b16be6f207fd0dcece9229
Previous-Reviewed-on: https://chromium-review.googlesource.com/190020
(cherry picked from commit d93d643d22e470fa2438d778e29773c0c30ae436)
Reviewed-on: https://chromium-review.googlesource.com/190504
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
CHROMIUM: Bluetooth: Add intel_btusb module for Intel Bluetooth device

Intel Bluetooth device (7260) requires device firmware patching before
the host send HCI initialization commands. This setup routine was added
in 3.10 kernel with a framework support from the Bluetooth subsystem
which is also introduced in 3.10 kernel.

Because the backporting this setup routine from 3.10 to 3.8 requires
also backporting Bluetooth framework change, which is significant in
the Bluetooth subsystem, it is not recommened by the Google maintainer.

Thus, intel_btusb module is forked from btusb module to have its own
device firmware setup routine without changing Bluetooth susbsystem.

Even if it is for Intel Bluetooth device, any other routines such as
submit USB urb, interrupt handling, and ISOC setup are same as btusb
module.

This is a custom patch for ChromeOS

BUG=chrome-os-partner:21770
TEST=tested with HID mouse and A2DP headset

Change-Id: Ic62d6794fb39b23db4ce31a303c04d9b5285ee8b
Reviewed-on: https://chromium-review.googlesource.com/190552
Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Tedd An <tedd.an@intel.com>
Tested-by: Tedd An <tedd.an@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/191281
Commit-Queue: Scott James Remnant <keybuk@chromium.org>
Tested-by: Scott James Remnant <keybuk@chromium.org>
UPSTREAM: mwifiex: use timeout variant for wait_event_interruptible

It has been observed that system hangs during suspend, if host
sleep activation fails due to a missing interrupt from firmware.
Use timeout variant, so that the thread will be woken up when
timer expires.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26770,26781,26916
TEST=run "suspend_stress_test" overnight and confirm no msgs
"GET_CMD_NODE: cmd node not available" in /var/log/messages.
There could be "cmd_wait_q terminated: -512" logs but they
should not cause system hang.

Change-Id: I50f3868fe6bf3c715fd7f185b54383eb22d804f2
Previous-Reviewed-on: https://chromium-review.googlesource.com/191026
(cherry picked from commit abc670e4e57ea256edadd75a1d7582d912bbb7fa)
Reviewed-on: https://chromium-review.googlesource.com/191620
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
UPSTREAM: mwifiex: cancel pending commands for signal

When a thread is interrupted by signal, all
wait_event_interruptible calls after queueing commands return
an error. Numbers of commands in pending queue are increased
in this case. Sometimes all commands nodes in pool are filled.

We will cancel pending commands when signal is received.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26770,26916
TEST=run "suspend_stress_test" overnight and confirm no msgs
"GET_CMD_NODE: cmd node not available" in /var/log/messages.

Change-Id: I04841c7991e570b269bde55485a13f0ada97afdc
Previous-Reviewed-on: https://chromium-review.googlesource.com/191025
(cherry picked from commit 21822d1eba05c151e6db562d2068b3eca2dee970)
Reviewed-on: https://chromium-review.googlesource.com/191630
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
UPSTREAM: mwifiex: scan command preparation failure handling

When scan request is received, scan commands are prepared and
queued into scan pending queue. There is a corner case when
command nodes are full. So we stop queueing further scan
commands and return an error. This patch makes sure that
currently queued commands in scan pending queue are also freed
in this case.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26770,26916
TEST=run "suspend_stress_test" overnight and confirm no msgs
"GET_CMD_NODE: cmd node not available" in /var/log/messages.

Change-Id: Ib61533ebb9636fb77731981005f90f43cec846a7
Previous-Reviewed-on: https://chromium-review.googlesource.com/191024
(cherry picked from commit 49157f36fff0fdd8a00c4f178aa930a09625de70)
Reviewed-on: https://chromium-review.googlesource.com/191632
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
UPSTREAM: mwifiex: abort scan while cancelling pending command

mwifiex_cancel_pending_ioctl() and
mwifiex_cancel_all_pending_cmd() are called in command timeout
and driver unload paths respectively.
If scan operation is in progress, we should abort it smoothly.

Reported-by: Tim Shepard <shep@alum.mit.edu>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:26626
TEST=run "./reload_network_device.sh mlan0; sleep 30" in a loop
for 50 times.

Change-Id: I44de2acf0d0cb7f72fbda45bd68037b9a259ffa8
Previous-Reviewed-on: https://chromium-review.googlesource.com/190810
(cherry picked from commit 8fe20cebfa39115befbb098fc5699847840568b5)
Reviewed-on: https://chromium-review.googlesource.com/191614
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
CHROMIUM: s5p-mfc: De-init MFC when watchdog kicks in

If the software watchdog kicks in, we need to de-init MFC
before reloading firmware and re-intializing it again.

BUG=chrome-os-partner:26961
TEST=Seek resolution change videos till it stops.
Open another video and observe it plays

Change-Id: I5f5a825c590f58842c11b52bfb58b14ab19793c5
Signed-off-by: Arun Mankuzhi <arun.m@samsung.com>
Previous-Reviewed-on: https://chromium-review.googlesource.com/190838
(cherry picked from commit adebe1ef091c4879fa4c9388af3348d8189fa232)
Reviewed-on: https://chromium-review.googlesource.com/191555
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
CHERRY-PICK: drm/anx7808: Increase delay at the end of power_off

This increases the delay at the end of the power_off routine to ensure
the value of the cable_det gpio is valid when we exit. The gpio bounces
as a result of powering down the chip, so waiting 25ms ensures that it's in
steady state.

BUG=chromium:351844
TEST=Tested on spring by entering/exiting docked mode repeatedly

Change-Id: Iad2efec2e8d4a8c722a8b7539fce006c3a9cb4dd
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190494
Reviewed-by: David Riley <davidriley@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
(cherry picked from commit f53dcd375ded6f31593ae90b07e77e47974bd2a6)
Reviewed-on: https://chromium-review.googlesource.com/191645
ARM: kernel: Create plat_cpu_resume to hold a pointer to resume

In some platform-agnostic code (like MCPM) we need a pointer to the
resume code.  Create a global variable that defaults to the generic
ARM resume code.  This allows platforms needing resume-time patches to
update the global.

A future patch will change mcpm to refer to this global.

BUG=chrome-os-partner:27270
TEST=See I1c8d3c48b2a6a617f71a965070aa3d8be6cad887 (with all patches)

Change-Id: I2e9bb358c7916e2ff326f1f60f967ea85d631c5f
Signed-off-by: Doug Anderson <dianders@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/191696
(cherry picked from commit 9b602262caf6469e8ec7da3f9b36c123449c50f5)
Reviewed-on: https://chromium-review.googlesource.com/191969
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Katie Roberts-Hoffman <katierh@chromium.org>
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
arm: bL_switcher: Use plat_cpu_resume to get the resume code

We may want to run a bit of platform specific code at resume time
before the generic ARM code runs.  Let's use the plat_cpu_resume
global to call the resume code so that we can get patches in.

BUG=chrome-os-partner:27270
TEST=See I1c8d3c48b2a6a617f71a965070aa3d8be6cad887 (with all patches)

Change-Id: I3970134682a8e4bb2e195294d9cfe2a9bce56fc3
Signed-off-by: Doug Anderson <dianders@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/191697
(cherry picked from commit f72b5051e5ec0b2240f9cec6a756abe7c35744db)
Reviewed-on: https://chromium-review.googlesource.com/192006
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Katie Roberts-Hoffman <katierh@chromium.org>
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
ARM: exynos542x: Adjust L2 cache timings at resume time

On the exynos5420 and exynos5422 we need to make sure that the Data
RAM Setup and Tag RAM Setup are both set to 1 in order for things to
be stable.  Unfortunately some early firmware shipped with devices
doesn't set this up properly.

We'll tweak the platform-specific resume code to detect exynos542x and
fix.

BUG=chrome-os-partner:27270
TEST=See I1c8d3c48b2a6a617f71a965070aa3d8be6cad887 (with all patches)

Change-Id: Ib4915d1bb05cf4f62328ee28881e31759116b502
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Previous-Reviewed-on: https://chromium-review.googlesource.com/191698
(cherry picked from commit 01db4c34cd0ca51859d87c9970d1a8be4a8c984d)
Reviewed-on: https://chromium-review.googlesource.com/192020
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Katie Roberts-Hoffman <katierh@chromium.org>
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
HACK: ARM: mm: Increase TAG and DATA RAM Setup on exynos542x at boot

In (ARM: exynos542x: Adjust L2 cache timings at resume time) we fix
the cache timings at resume time (and thus whenever we switch from an
A7 to an A15), but we don't fix them at boot time.

Close the gap in time when the L2 cache timings are wrong by making
sure that we also adjust the timings at boot.

If/when we release a RW firmware update on pit and pi we can safely
revert this patch.

Before this change:
Data RAM Latency is 010 i.e. 3
Data RAM Slice = 1
Data RAM Setup = 0
So effective Data RAM Latency is 5

Tag RAM latency is 010 i.e. 3
Tag RAM Setup = 0
Tag RAM Slice = 0
So effective Tag RAM Latency is 3.

After this change:
Now, make Data Setup -> 1, Tag RAM setup -> 1

So effective Data RAM Latency is 6
So effective Tag RAM Latency is 4

BUG=chrome-os-partner:27270
TEST=Factory stress test on Pit and Pi shows no more hangs.

Change-Id: I5a155529655161dfd66384d2e549ae45e9921bd9
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/191670
(cherry picked from commit 06e321fc625b0dc6d8fb65738d35d39d4336d700)
Reviewed-on: https://chromium-review.googlesource.com/192007
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Katie Roberts-Hoffman <katierh@chromium.org>
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
drm/exynos: add support for 1600x900

This patch adds new resoluton range of 1600x900
in the range of supported resolutions.

BUG=chrome-os-partner:26914
TEST=connect monitor with max/best resolution supported
as 1600x900 and verifed 1600x900 is selected on HDMI

Change-Id: I1e56f08092653c8c37c79c406178f64aa3f6c16e
Signed-off-by: Shirish S <s.shirish@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/190267
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Wonjoon Lee <woojoo.lee@samsung.com>
UPSTREAM: mwifiex: corner case NULL pointer dereference fix

When next scan command is delayed due to Tx traffic and
meanwhile synchronous command is received followed by a signal,
we cance all pending commands. NULL pointer dereference is seen
in this case while queueing next command in scan delay timer.
This patch adds a check to fix this issue.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26770,26916
TEST=run "suspend_stress_test" overnight on peach and confirm
no NULL pointer dereference at PC=mwifiex_insert_cmd_to_pending_q,
LR=scan_delay_timer_fn().

Change-Id: I708e2c691ec841e3eb4c4453462e3affafffba69
Previous-Reviewed-on: https://chromium-review.googlesource.com/191640
(cherry picked from commit 57fdd9ba9ed20787a2f2a287abfdaf15b030492b)
Reviewed-on: https://chromium-review.googlesource.com/191694
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
UPSTREAM: mwifiex: correction in sleep confirm command sequence
 number

Incremented sequence number was not being used for SLEEP confirm
command. This patch fixes the issue.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=none
TEST=enable driver log and check the sequence number of sleep_cfm
command is increased by one.

Change-Id: I1b80b6751ec5e27b7142bf1a02dc3202915e3a31
Previous-Reviewed-on: https://chromium-review.googlesource.com/191641
(cherry picked from commit 6d723dede9503f91cde295260196338ab7ea430f)
Reviewed-on: https://chromium-review.googlesource.com/191720
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
UPSTREAM: mwifiex: cancel pending commands during host sleep

Sometimes we may end up downloading other commands when host
sleep is configured. This patch makes sure that pending
commands are cancelled and we stop queueing further commands
during host sleep.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26770,26916
TEST=enable driver cmd logs, run "suspend_stress_test" overnight
on peach and confirm that hs_cfg and hs_activated happens
atomically based on the logs, i.e., no command being sent
between "hs_cfg command response is received" and "hs_activated".

Change-Id: I1e8c329bd600500e27fcc2936de5449f8371ac78
Previous-Reviewed-on: https://chromium-review.googlesource.com/191642
(cherry picked from commit 06f99d8b45809770d1d78a031ff605fd14aee1d5)
Reviewed-on: https://chromium-review.googlesource.com/191703
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
UPSTREAM: mwifiex: fix spinlock bad magic bug

[ 6630.450908] BUG: spinlock bad magic on CPU#1,
               ksdioirqd/mmc1/355
[ 6630.450914] Unable to handle kernel NULL pointer dereference
               at virtual address 0000004f
[ 6630.450919] pgd = ecbd8000
[ 6630.450926] [0000004f] *pgd=00000000
[ 6630.450936]  lock: 0xeea4ab08, .magic: 00000000,
               .owner: <none>/-1, .owner_cpu: 0
[ 6630.450939] Backtrace:
[ 6630.450956] [<c010d354>] (unwind_backtrace+0x0/0x118) from
               [<c060c238>] (dump_stack+0x28/0x30)
[ 6630.450960] Internal error: Oops: 5 [#1] SMP ARM
[ 6630.450964] Modules linked in: uvcvideo videobuf2_vmalloc
[ 6630.450980] [<c060c238>] (dump_stack+0x28/0x30) from
               [<c0315ab4>] (spin_dump+0x80/0x94)
[ 6630.450988] [<c0315ab4>] (spin_dump+0x80/0x94) from
               [<c0315af4>] (spin_bug+0x2c/0x30)
[ 6630.450996] [<c0315af4>] (spin_bug+0x2c/0x30) from
               [<c0315b80>] (do_raw_spin_lock+0x28/0x15c)
[ 6630.451004] [<c0315b80>] (do_raw_spin_lock+0x28/0x15c) from
               [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 6630.451016] [<c0610c24>] (_raw_spin_lock_irqsave+0x20/0x28)
               from [<bf07a7f4>] (mwifiex_exec_next_cmd
                                  +0x6c/0x45c [mwifiex])
[ 6630.451030] [<bf07a7f4>] (mwifiex_exec_next_cmd+0x6c/0x45c
               [mwifiex]) from [<bf07834c>]
               (mwifiex_main_process+0x2c8/0x464 [mwifiex])
[ 6630.451047] [<bf07834c>] (mwifiex_main_process+0x2c8/0x464
               [mwifiex]) from [<bf0a093c>]
               (mwifiex_sdio_interrupt+0xc8/0x1cc [mwifiex_sdio]
[ 6630.451064] [<bf0a093c>] (mwifiex_sdio_interrupt+0xc8/0x1cc
               [mwifiex_sdio]) from [<c04bbde0>]
               (sdio_irq_thread+0x178/0x31c)
[ 6630.451079] [<c04bbde0>] (sdio_irq_thread+0x178/0x31c) from
               [<c0145514>] (kthread+0xc8/0xd8)
[ 6630.451095] [<c0145514>] (kthread+0xc8/0xd8) from
               [<c0106118>] (ret_from_fork+0x14/0x20)

This bug has introduced/exposed due to recent patch in which we
cancel pending commands before suspend (using hs_enabling flag).
The NULL pointer is dereferenced when both
mwifiex_cancel_all_pending_cmd() and mwifiex_exec_next_cmd()
try to access cmd pending queue simultaneously.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=chrome-os-partner:26770,26916
TEST=run "suspend_stress_test" overnight and don't get
"BUG: spinlock bad magic" kernel panic.

Change-Id: Ia4bcc8b642d18dfacf9c70086d9f2d5692cf1ab8
Previous-Reviewed-on: https://chromium-review.googlesource.com/192050
(cherry picked from commit 078317199ec7946aa866f4b83d398913c3fcc5ea)
Reviewed-on: https://chromium-review.googlesource.com/192479
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: mukesh agrawal <quiche@chromium.org>
Tested-by: mukesh agrawal <quiche@chromium.org>
UPSTREAM: Bluetooth: btmrvl: don't consume all vendor specific events

If vendor specific HCI commands are received from application,
we should send corresponding events to stack.
These events should be consumed in driver, only if they are for
the internal HCI commands generated by driver.

This patch fixes the vendor command 0x3f stuck problem with
above mentioned change. For example,

hcitool cmd 3f 22 fe 06 22 21 20 43 50 00

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

BUG=chrome-os-partner:27124
TEST="hcitool cmd 3f 22 fe 06 22 21 20 43 50 00" command succeeds.

Change-Id: If79ed4f7cedf623813e303644fa6fc9d9da2caee
Reviewed-on: https://chromium-review.googlesource.com/191040
Reviewed-by: Scott James Remnant <keybuk@chromium.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
(cherry picked from commit af8da59055f6eb13bf2d3f56b1ea5e0320410dd9)
Reviewed-on: https://chromium-review.googlesource.com/192597
Commit-Queue: Katie Roberts-Hoffman <katierh@chromium.org>
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>