I'm building images for an EMBEDDED platform, and forcing CONFIG_SSB_POSSIBLE=n, but I'm still seeing:
*
* Sonics Silicon Backplane
*
Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
Support for the Sonics Silicon Backplane bus.
You only need to enable this option, if you are
configuring a kernel for an embedded system with
this bus.
It will be auto-selected if needed in other
environments.
The module will be called ssb.
If unsure, say N.
Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
Support for the Sonics Silicon Backplane bus.
You only need to enable this option, if you are
configuring a kernel for an embedded system with
this bus.
It will be auto-selected if needed in other
environments.
The module will be called ssb.
If unsure, say N.
Sonics Silicon Backplane support (SSB) [M/y/?] (NEW)
And why does arch/x86/configs/i386_defconfig nail up CONFIG_SSB_POSSIBLE?
This is with 2.6.27.38.
And what are the steps to figuring out the dependency that keeps forcing it on? Something must be doing a "select SSB" but I'm not sure what.
On 12/21/2009 08:09 AM, Randy Dunlap wrote:
> On Sun, 20 Dec 2009 20:22:19 -0800 Philip A. Prindeville wrote:
>
>> On 12/20/2009 05:50 PM, Randy Dunlap wrote:
>>> On Sun, 20 Dec 2009 17:16:34 -0800 Philip A. Prindeville wrote:
>>>
>>>> I'm building images for an EMBEDDED platform, and forcing CONFIG_SSB_POSSIBLE=n, but I'm still seeing:
>>>
>>> What $ARCH ?
>>
>> i586.
>>
>>
>>>
>>>> *
>>>> * Sonics Silicon Backplane
>>>> *
>>>> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
>>>>
>>>> Support for the Sonics Silicon Backplane bus.
>>>> You only need to enable this option, if you are
>>>> configuring a kernel for an embedded system with
>>>> this bus.
>>>> It will be auto-selected if needed in other
>>>> environments.
>>>>
>>>> The module will be called ssb.
>>>>
>>>> If unsure, say N.
>>>>
>>>> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
>>>>
>>>> Support for the Sonics Silicon Backplane bus.
>>>> You only need to enable this option, if you are
>>>> configuring a kernel for an embedded system with
>>>> this bus.
>>>> It will be auto-selected if needed in other
>>>> environments.
>>>>
>>>> The module will be called ssb.
>>>>
>>>> If unsure, say N.
>>>>
>>>> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW)
>>>>
>>>>
>>>>
>>>> And why does arch/x86/configs/i386_defconfig nail up CONFIG_SSB_POSSIBLE?
>>>
>>> That just means that SSB support is possible:
>>>
>>> config SSB_POSSIBLE
>>> bool
>>> depends on HAS_IOMEM && HAS_DMA
>>> default y
>>>
>>> Shouldn't be a problem.
>>>
>>>> This is with 2.6.27.38.
>>>>
>>>> And what are the steps to figuring out the dependency that keeps forcing it on? Something must be doing a "select SSB" but I'm not sure what.
>>>
>>> Are you using b43 or b44 network drivers?
>>
>> Neither.
>>
>> I can attach the .config we're using, if you want...
>
> Sure, if you are still having problems with it.
>
> ---
> ~Randy
Here's what we have.
-Philip
On Monday 21 December 2009 20:06:13 Philip A. Prindeville wrote:
> On 12/21/2009 10:45 AM, Michael Buesch wrote:
> > On Monday 21 December 2009 19:31:06 Philip A. Prindeville wrote:
> >> Here's what we have.
> >
> > # CONFIG_SSB is not set
> >
>
> Ok, here's what's happening.
>
> We have a "canned" config that we copy over, per platform.
>
> I'm showing diffs of that config with what results (i.e. what's left in the linux-2.6.27.38 directory after running "make silentoldconfig" and "make prepare1"):
>
> --- target/device/via-c7/linux.config 2009-12-21 10:55:55.000000000 -0800
> +++ build_i586/linux-2.6.27.38-astlinux/.config 2009-12-21 11:02:34.000000000 -0800
> @@ -1,7 +1,7 @@
> #
> # Automatically generated make config: don't edit
> # Linux kernel version: 2.6.27.38
> -# Tue Nov 10 16:50:01 2009
> +# Mon Dec 21 11:02:34 2009
> #
> # CONFIG_64BIT is not set
> CONFIG_X86_32=y
> @@ -1446,8 +1446,16 @@
> #
> # Sonics Silicon Backplane
> #
> -CONFIG_SSB_POSSIBLE=n
> -CONFIG_SSB=n
> +CONFIG_SSB_POSSIBLE=y
> +CONFIG_SSB=m
> +CONFIG_SSB_SPROM=y
> +CONFIG_SSB_PCIHOST_POSSIBLE=y
> +CONFIG_SSB_PCIHOST=y
> +# CONFIG_SSB_B43_PCI_BRIDGE is not set
> +# CONFIG_SSB_SILENT is not set
> +# CONFIG_SSB_DEBUG is not set
> +CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
> +CONFIG_SSB_DRIVER_PCICORE=y
>
> #
> # Multifunction device drivers
> @@ -1621,6 +1629,8 @@
> # CONFIG_USB_DYNAMIC_MINORS is not set
> # CONFIG_USB_SUSPEND is not set
> # CONFIG_USB_OTG is not set
> +# CONFIG_USB_OTG_WHITELIST is not set
> +# CONFIG_USB_OTG_BLACKLIST_HUB is not set
> # CONFIG_USB_MON is not set
>
> #
> @@ -1955,7 +1965,7 @@
> CONFIG_DEBUG_FS=y
> # CONFIG_HEADERS_CHECK is not set
> # CONFIG_DEBUG_KERNEL is not set
> -CONFIG_DEBUG_BUGVERBOSE=y
> +# CONFIG_DEBUG_BUGVERBOSE is not set
> CONFIG_DEBUG_MEMORY_INIT=y
> # CONFIG_LATENCYTOP is not set
> CONFIG_SYSCTL_SYSCALL_CHECK=y
>
>
> as you can see, a bunch of things are getting "turned on" that we explicitly turned off.
>
> -Philip
>
>
>
That is expected, because you have
CONFIG_B44=m
--
Greetings, Michael.
On 12/21/2009 12:24 AM, Holger Schurig wrote:
>> And what are the steps to figuring out the dependency that
>> keeps forcing it on? Something must be doing a "select SSB"
>> but I'm not sure what.
>
> "make xconfig", and then turn on "Options -> Show Debug Info".
>
> Then you see the reverse dep.
>
>
> Another thing would be "find -name Kconfig |xargs grep
> SSB_POSSIBLE" and then carefully check those files.
Well, as I mentioned, arch/x86/configs/i386_defconfig contains:
CONFIG_SSB_POSSIBLE=y
which I've not been able to understand why. There are lots of x86 configurations where this might *not* be possible, in embedded platforms in particular.
-Philip
> And what are the steps to figuring out the dependency that
> keeps forcing it on? Something must be doing a "select SSB"
> but I'm not sure what.
"make xconfig", and then turn on "Options -> Show Debug Info".
Then you see the reverse dep.
Another thing would be "find -name Kconfig |xargs grep
SSB_POSSIBLE" and then carefully check those files.
--
http://www.holgerschurig.de
Philipp, your server is bouncing mail (just in case you read the list archives or whatever :D):
> [email protected]
> SMTP error from remote mail server after initial connection:
> host mail.redfish-solutions.com [66.232.79.143]:
> 554 mail.redfish-solutions.com ESMTP not accepting messages
--
Greetings, Michael.
On Monday 21 December 2009 20:07:47 Philip A. Prindeville wrote:
> The issue is that later on when we build compat-wireless, then my .config file from the linux build directory gets sourced by that and we get a bunch of warnings from the b43, b44, etc. drivers that some ssb_* entry points are missing.
So, disable these drivers?
--
Greetings, Michael.
On 12/21/2009 10:59 AM, John W. Linville wrote:
> On Mon, Dec 21, 2009 at 10:51:16AM -0800, Philip A. Prindeville wrote:
>> On 12/21/2009 12:24 AM, Holger Schurig wrote:
>>>> And what are the steps to figuring out the dependency that
>>>> keeps forcing it on? Something must be doing a "select SSB"
>>>> but I'm not sure what.
>>>
>>> "make xconfig", and then turn on "Options -> Show Debug Info".
>>>
>>> Then you see the reverse dep.
>>>
>>>
>>> Another thing would be "find -name Kconfig |xargs grep
>>> SSB_POSSIBLE" and then carefully check those files.
>>
>> Well, as I mentioned, arch/x86/configs/i386_defconfig contains:
>>
>> CONFIG_SSB_POSSIBLE=y
>>
>> which I've not been able to understand why. There are lots of x86 configurations where this might *not* be possible, in embedded platforms in particular.
>
> config SSB_POSSIBLE
> bool
> depends on HAS_IOMEM && HAS_DMA
> default y
>
> What x86 configurations don't have IOMEM or DMA? And what difference
> does it make if SSB_POSSIBLE is defined if it doesn't build any code?
>
> John
The issue is that later on when we build compat-wireless, then my .config file from the linux build directory gets sourced by that and we get a bunch of warnings from the b43, b44, etc. drivers that some ssb_* entry points are missing.
On Mon, 21 Dec 2009 11:06:13 -0800 Philip A. Prindeville wrote:
> On 12/21/2009 10:45 AM, Michael Buesch wrote:
> > On Monday 21 December 2009 19:31:06 Philip A. Prindeville wrote:
> >> Here's what we have.
> >
> > # CONFIG_SSB is not set
> >
>
> Ok, here's what's happening.
>
> We have a "canned" config that we copy over, per platform.
>
> I'm showing diffs of that config with what results (i.e. what's left in the linux-2.6.27.38 directory after running "make silentoldconfig" and "make prepare1"):
>
> --- target/device/via-c7/linux.config 2009-12-21 10:55:55.000000000 -0800
> +++ build_i586/linux-2.6.27.38-astlinux/.config 2009-12-21 11:02:34.000000000 -0800
> @@ -1,7 +1,7 @@
> #
> # Automatically generated make config: don't edit
> # Linux kernel version: 2.6.27.38
> -# Tue Nov 10 16:50:01 2009
> +# Mon Dec 21 11:02:34 2009
> #
> # CONFIG_64BIT is not set
> CONFIG_X86_32=y
> @@ -1446,8 +1446,16 @@
> #
> # Sonics Silicon Backplane
> #
> -CONFIG_SSB_POSSIBLE=n
> -CONFIG_SSB=n
> +CONFIG_SSB_POSSIBLE=y
> +CONFIG_SSB=m
> +CONFIG_SSB_SPROM=y
> +CONFIG_SSB_PCIHOST_POSSIBLE=y
> +CONFIG_SSB_PCIHOST=y
> +# CONFIG_SSB_B43_PCI_BRIDGE is not set
> +# CONFIG_SSB_SILENT is not set
> +# CONFIG_SSB_DEBUG is not set
> +CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
> +CONFIG_SSB_DRIVER_PCICORE=y
>
> #
> # Multifunction device drivers
> @@ -1621,6 +1629,8 @@
> # CONFIG_USB_DYNAMIC_MINORS is not set
> # CONFIG_USB_SUSPEND is not set
> # CONFIG_USB_OTG is not set
> +# CONFIG_USB_OTG_WHITELIST is not set
> +# CONFIG_USB_OTG_BLACKLIST_HUB is not set
> # CONFIG_USB_MON is not set
>
> #
> @@ -1955,7 +1965,7 @@
> CONFIG_DEBUG_FS=y
> # CONFIG_HEADERS_CHECK is not set
> # CONFIG_DEBUG_KERNEL is not set
> -CONFIG_DEBUG_BUGVERBOSE=y
> +# CONFIG_DEBUG_BUGVERBOSE is not set
> CONFIG_DEBUG_MEMORY_INIT=y
> # CONFIG_LATENCYTOP is not set
> CONFIG_SYSCTL_SYSCALL_CHECK=y
>
>
> as you can see, a bunch of things are getting "turned on" that we explicitly turned off.
Your custom config seems to enable B44, which selects SSB.
Can you disable B44?
---
~Randy
On Monday 21 December 2009 19:31:06 Philip A. Prindeville wrote:
> Here's what we have.
# CONFIG_SSB is not set
--
Greetings, Michael.
On Monday 21 December 2009 02:16:34 Philip A. Prindeville wrote:
> I'm building images for an EMBEDDED platform, and forcing CONFIG_SSB_POSSIBLE=n, but I'm still seeing:
>
> *
> * Sonics Silicon Backplane
> *
> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
>
> Support for the Sonics Silicon Backplane bus.
> You only need to enable this option, if you are
> configuring a kernel for an embedded system with
> this bus.
> It will be auto-selected if needed in other
> environments.
>
> The module will be called ssb.
>
> If unsure, say N.
>
> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
>
> Support for the Sonics Silicon Backplane bus.
> You only need to enable this option, if you are
> configuring a kernel for an embedded system with
> this bus.
> It will be auto-selected if needed in other
> environments.
>
> The module will be called ssb.
>
> If unsure, say N.
>
> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW)
>
>
>
> And why does arch/x86/configs/i386_defconfig nail up CONFIG_SSB_POSSIBLE?
>
> This is with 2.6.27.38.
>
> And what are the steps to figuring out the dependency that keeps forcing it on? Something must be doing a "select SSB" but I'm not sure what.
CONFIG_SSB_POSSIBLE is just a management config entry that does not affect compilation.
It's just used to get the dependencies right. As long as CONFIG_SSB is n, no SSB code will
be built. CONFIG_SSB_POSSIBLE does just indicate whether it's possible to enable SSB. No more
and no less. It's just used as a dependency for the other modules that do a "select SSB".
The drivers that automatically select CONFIG_SSB are:
- bcm47xx MIPS platform
- bcm63xx MIPS platform
- b43 driver
- b43legacy driver
- b44 driver
--
Greetings, Michael.
On Sun, 20 Dec 2009 17:16:34 -0800 Philip A. Prindeville wrote:
> I'm building images for an EMBEDDED platform, and forcing CONFIG_SSB_POSSIBLE=n, but I'm still seeing:
What $ARCH ?
> *
> * Sonics Silicon Backplane
> *
> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
>
> Support for the Sonics Silicon Backplane bus.
> You only need to enable this option, if you are
> configuring a kernel for an embedded system with
> this bus.
> It will be auto-selected if needed in other
> environments.
>
> The module will be called ssb.
>
> If unsure, say N.
>
> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
>
> Support for the Sonics Silicon Backplane bus.
> You only need to enable this option, if you are
> configuring a kernel for an embedded system with
> this bus.
> It will be auto-selected if needed in other
> environments.
>
> The module will be called ssb.
>
> If unsure, say N.
>
> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW)
>
>
>
> And why does arch/x86/configs/i386_defconfig nail up CONFIG_SSB_POSSIBLE?
That just means that SSB support is possible:
config SSB_POSSIBLE
bool
depends on HAS_IOMEM && HAS_DMA
default y
Shouldn't be a problem.
> This is with 2.6.27.38.
>
> And what are the steps to figuring out the dependency that keeps forcing it on? Something must be doing a "select SSB" but I'm not sure what.
Are you using b43 or b44 network drivers?
---
~Randy
On 12/21/2009 10:45 AM, Michael Buesch wrote:
> On Monday 21 December 2009 19:31:06 Philip A. Prindeville wrote:
>> Here's what we have.
>
> # CONFIG_SSB is not set
>
Ok, here's what's happening.
We have a "canned" config that we copy over, per platform.
I'm showing diffs of that config with what results (i.e. what's left in the linux-2.6.27.38 directory after running "make silentoldconfig" and "make prepare1"):
--- target/device/via-c7/linux.config 2009-12-21 10:55:55.000000000 -0800
+++ build_i586/linux-2.6.27.38-astlinux/.config 2009-12-21 11:02:34.000000000 -0800
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.27.38
-# Tue Nov 10 16:50:01 2009
+# Mon Dec 21 11:02:34 2009
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
@@ -1446,8 +1446,16 @@
#
# Sonics Silicon Backplane
#
-CONFIG_SSB_POSSIBLE=n
-CONFIG_SSB=n
+CONFIG_SSB_POSSIBLE=y
+CONFIG_SSB=m
+CONFIG_SSB_SPROM=y
+CONFIG_SSB_PCIHOST_POSSIBLE=y
+CONFIG_SSB_PCIHOST=y
+# CONFIG_SSB_B43_PCI_BRIDGE is not set
+# CONFIG_SSB_SILENT is not set
+# CONFIG_SSB_DEBUG is not set
+CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
+CONFIG_SSB_DRIVER_PCICORE=y
#
# Multifunction device drivers
@@ -1621,6 +1629,8 @@
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
+# CONFIG_USB_OTG_WHITELIST is not set
+# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_MON is not set
#
@@ -1955,7 +1965,7 @@
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
-CONFIG_DEBUG_BUGVERBOSE=y
+# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
as you can see, a bunch of things are getting "turned on" that we explicitly turned off.
-Philip
On Sun, 20 Dec 2009 20:22:19 -0800 Philip A. Prindeville wrote:
> On 12/20/2009 05:50 PM, Randy Dunlap wrote:
> > On Sun, 20 Dec 2009 17:16:34 -0800 Philip A. Prindeville wrote:
> >
> >> I'm building images for an EMBEDDED platform, and forcing CONFIG_SSB_POSSIBLE=n, but I'm still seeing:
> >
> > What $ARCH ?
>
> i586.
>
>
> >
> >> *
> >> * Sonics Silicon Backplane
> >> *
> >> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
> >>
> >> Support for the Sonics Silicon Backplane bus.
> >> You only need to enable this option, if you are
> >> configuring a kernel for an embedded system with
> >> this bus.
> >> It will be auto-selected if needed in other
> >> environments.
> >>
> >> The module will be called ssb.
> >>
> >> If unsure, say N.
> >>
> >> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
> >>
> >> Support for the Sonics Silicon Backplane bus.
> >> You only need to enable this option, if you are
> >> configuring a kernel for an embedded system with
> >> this bus.
> >> It will be auto-selected if needed in other
> >> environments.
> >>
> >> The module will be called ssb.
> >>
> >> If unsure, say N.
> >>
> >> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW)
> >>
> >>
> >>
> >> And why does arch/x86/configs/i386_defconfig nail up CONFIG_SSB_POSSIBLE?
> >
> > That just means that SSB support is possible:
> >
> > config SSB_POSSIBLE
> > bool
> > depends on HAS_IOMEM && HAS_DMA
> > default y
> >
> > Shouldn't be a problem.
> >
> >> This is with 2.6.27.38.
> >>
> >> And what are the steps to figuring out the dependency that keeps forcing it on? Something must be doing a "select SSB" but I'm not sure what.
> >
> > Are you using b43 or b44 network drivers?
>
> Neither.
>
> I can attach the .config we're using, if you want...
Sure, if you are still having problems with it.
---
~Randy
On Mon, 21 Dec 2009 10:51:16 -0800 Philip A. Prindeville wrote:
> On 12/21/2009 12:24 AM, Holger Schurig wrote:
> >> And what are the steps to figuring out the dependency that
> >> keeps forcing it on? Something must be doing a "select SSB"
> >> but I'm not sure what.
> >
> > "make xconfig", and then turn on "Options -> Show Debug Info".
> >
> > Then you see the reverse dep.
> >
> >
> > Another thing would be "find -name Kconfig |xargs grep
> > SSB_POSSIBLE" and then carefully check those files.
>
> Well, as I mentioned, arch/x86/configs/i386_defconfig contains:
>
> CONFIG_SSB_POSSIBLE=y
That is =y iff:
config SSB_POSSIBLE
bool
depends on HAS_IOMEM && HAS_DMA
default y
HAS_IOMEM=y and HAS_DMA=y. Aren't those both =y on your platform?
Other than being set, it shouldn't be hurting anything.
> which I've not been able to understand why. There are lots of x86 configurations where this might *not* be possible, in embedded platforms in particular.
---
~Randy
On Mon, Dec 21, 2009 at 10:51:16AM -0800, Philip A. Prindeville wrote:
> On 12/21/2009 12:24 AM, Holger Schurig wrote:
> >> And what are the steps to figuring out the dependency that
> >> keeps forcing it on? Something must be doing a "select SSB"
> >> but I'm not sure what.
> >
> > "make xconfig", and then turn on "Options -> Show Debug Info".
> >
> > Then you see the reverse dep.
> >
> >
> > Another thing would be "find -name Kconfig |xargs grep
> > SSB_POSSIBLE" and then carefully check those files.
>
> Well, as I mentioned, arch/x86/configs/i386_defconfig contains:
>
> CONFIG_SSB_POSSIBLE=y
>
> which I've not been able to understand why. There are lots of x86 configurations where this might *not* be possible, in embedded platforms in particular.
config SSB_POSSIBLE
bool
depends on HAS_IOMEM && HAS_DMA
default y
What x86 configurations don't have IOMEM or DMA? And what difference
does it make if SSB_POSSIBLE is defined if it doesn't build any code?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On 12/20/2009 05:50 PM, Randy Dunlap wrote:
> On Sun, 20 Dec 2009 17:16:34 -0800 Philip A. Prindeville wrote:
>
>> I'm building images for an EMBEDDED platform, and forcing CONFIG_SSB_POSSIBLE=n, but I'm still seeing:
>
> What $ARCH ?
i586.
>
>> *
>> * Sonics Silicon Backplane
>> *
>> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
>>
>> Support for the Sonics Silicon Backplane bus.
>> You only need to enable this option, if you are
>> configuring a kernel for an embedded system with
>> this bus.
>> It will be auto-selected if needed in other
>> environments.
>>
>> The module will be called ssb.
>>
>> If unsure, say N.
>>
>> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW) n
>>
>> Support for the Sonics Silicon Backplane bus.
>> You only need to enable this option, if you are
>> configuring a kernel for an embedded system with
>> this bus.
>> It will be auto-selected if needed in other
>> environments.
>>
>> The module will be called ssb.
>>
>> If unsure, say N.
>>
>> Sonics Silicon Backplane support (SSB) [M/y/?] (NEW)
>>
>>
>>
>> And why does arch/x86/configs/i386_defconfig nail up CONFIG_SSB_POSSIBLE?
>
> That just means that SSB support is possible:
>
> config SSB_POSSIBLE
> bool
> depends on HAS_IOMEM && HAS_DMA
> default y
>
> Shouldn't be a problem.
>
>> This is with 2.6.27.38.
>>
>> And what are the steps to figuring out the dependency that keeps forcing it on? Something must be doing a "select SSB" but I'm not sure what.
>
> Are you using b43 or b44 network drivers?
Neither.
I can attach the .config we're using, if you want...
-Philip
> ---
> ~Randy