are you trying to add an i2c device to the sensor framework? or are you asking
how to touch i2c devices from userland?
> On 21 Mar 2022, at 16:21, Dr. T.I.S. wrote:
>
> I know the rule, try to research first on man pages, openbsd.org, ect,
> and ask people as a last resort. Unfortunately, I ha
I know the rule, try to research first on man pages, openbsd.org, ect,
and ask people as a last resort. Unfortunately, I have exhausted
all resources online that I could find. (I was recommend to use this
email list by OpenBSd dev on reddit)
Currently, I am trying to use I2C on the latest version
in_pcbselsrc has this:
ifp = if_get(mopts->imo_ifidx);
if (ifp != NULL) {
if (ifp->if_rdomain == rtable_l2(rtableid))
IFP_TO_IA(ifp, ia);
if (ia == NULL) {
On Sat, Mar 19, 2022 at 09:15:23PM +0100, Stefan Sperling wrote:
[...]
> > + /* XBox One controller initialization */
>
> Shouldn't this initialization code be under #ifndef SMALL_KERNEL,
> like the rest of the code your patch is adding to this file?
>
> > + if (sc->sc_flags
On 2022/03/20 18:13, Stuart Henderson wrote:
> On 2022/03/20 18:13, Solene Rapenne wrote:
> > I'm proposing a very simple change to the automatic policy of the CPU
> > frequency scheduler.
> >
> > Currently, every 100ms the scheduler is doing this:
> >
> > - when the CPU load exceeds the threshol
On 2022 Mar 20 (Sun) at 18:13:20 + (+), Stuart Henderson wrote:
:On 2022/03/20 18:13, Solene Rapenne wrote:
:> I'm proposing a very simple change to the automatic policy of the CPU
:> frequency scheduler.
:>
:> Currently, every 100ms the scheduler is doing this:
:>
:> - when the CPU load
On 2022/03/20 18:13, Solene Rapenne wrote:
> I'm proposing a very simple change to the automatic policy of the CPU
> frequency scheduler.
>
> Currently, every 100ms the scheduler is doing this:
>
> - when the CPU load exceeds the threshold, CPU frequency is set to the
> maximum and the variable
On Thu, Mar 10, 2022 at 08:19:33PM +0300, Mikhail wrote:
> Replace rsync command with openrsync in EXAMPLES.
>
sorry, i think this one got overlooked! you can check in the archives,
but i think the consensus was that when it's ready openrsync will be
renamed but, for now, the examples should stay
This patch fixes a couple of issues in the VHT rate adaptation code,
and with the data which iwm(4) is feeding into it.
Testing 11ac mode from a distance to my AP, I found that iwm(4) tends
to pick a Tx rate which is too high, resulting in too much of a drop
in throughput.
With this patch, iwm(4)
Hi,
>> A downside of this is that it becomes easier to guess the addresses
>> of the tagged variables.
> No kidding. It partly undoes the effort of KARL.
I don't feel qualified to comment on the patch,
but i can't resist mentioning that i still love
tedu@'s classical dictum "attack mitigation
OK
On 2022/03/19 20:37, Stefan Sperling wrote:
> Both iwm and iwx are currently writing VHT capabilities into
> the "common" secion of the firmware's probe request frame template.
> This "common" section is used on both 2GHz and 5GHz bands.
>
> Announcing VHT capabilities on 2GHz makes no sense.
> A downside of this is that it becomes easier to guess the addresses
> of the tagged variables.
No kidding. It partly undoes the effort of KARL.
Le Sat, Mar 19, 2022 at 05:21:55PM +0100, Stefan Sperling a écrit :
> On Fri, Mar 18, 2022 at 11:36:50AM +0100, Stefan Sperling wrote:
> > On Fri, Mar 18, 2022 at 05:25:42AM +0100, Landry Breuil wrote:
> > > interestingly, when associated over ac to the livebox the background
> > > scans only shows
13 matches
Mail list logo
