Hi
I want to port the pinctrl-cherryview driver from Linux.
I've seen there is the gpiobus and a controller gpioc, can any of these be
leverage when porting pinctrl?
What is the recommend way to proceed?
Thanks!
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On 2016-Jun-2, at 11:11 AM, Bryan Drewery wrote:
> On 6/2/2016 10:53 AM, Simon J. Gerraty wrote:
>> BTW Mark, thanks very much for testing this.
>>
# grep make_keys
~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-2016-06-01:15:17:28
Building
Mark Millard wrote:
> > # grep -i make /usr/sbin/mergemaster | more
> . . .
> > MM_MAKE="make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk"
> > ${MM_MAKE} DESTDIR=${DESTDIR} distrib-dirs >/dev/null
> > ${MM_MAKE} DESTDIR=${TEMPROOT} distrib-dirs >/dev/null &&
> >
mergemaster [as an example] has code like:
> # grep -i make /usr/sbin/mergemaster | more
. . .
> MM_MAKE="make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk"
> ${MM_MAKE} DESTDIR=${DESTDIR} distrib-dirs >/dev/null
> ${MM_MAKE} DESTDIR=${TEMPROOT} distrib-dirs >/dev/null &&
>
Also, on my system running nda, smartmontools work. And the latest version
is compiling in Netflix's tree, which is where I took all these patches from...
Warner
On Sat, Jun 11, 2016 at 5:57 PM, Warner Losh wrote:
> I'm skeptical. The ATA stuff isn't anything that I've
I'm skeptical. The ATA stuff isn't anything that I've committed to, so
that isn't new.
The nvme stuff is because smartmontools defines nvme stuff that
conflicts with the FreeBSD defines...
Warner
On Sat, Jun 11, 2016 at 9:42 AM, Ngie Cooper (yaneurabeya)
wrote:
>
>> On
On Sat, Jun 11, 2016 at 5:32 AM, Domagoj Stolfa
wrote:
> Yes, it would maybe make sense to do so. I am not too familiar with
> capsicum(4), but glancing over it, it might be possible. If anything, it
> would allow for code reuse from the OpenBSD ports and increased
Hello,
thank you for importing NetBSD's blacklistd into FreeBSD, that
really was great news! For those of us who don't want to have
a logfile analyzer running that needs to reevaluate things which
the program who produced the entry already knew.
I have my very own exposed server since 2016, the
> On Jun 11, 2016, at 09:40, Michael Butler wrote:
>
> The recent nvme updates have broken smartmontools ..
>
> imb@toshi:/home/imb> sudo smartctl -a /dev/ada0
> smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-ALPHA2 amd64] (local build)
> Copyright (C) 2002-16, Bruce
The recent nvme updates have broken smartmontools ..
imb@toshi:/home/imb> sudo smartctl -a /dev/ada0
smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-ALPHA2 amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
/dev/ada0: Inappropriate ioctl for device
Yes, it would maybe make sense to do so. I am not too familiar with
capsicum(4), but glancing over it, it might be possible. If anything, it
would allow for code reuse from the OpenBSD ports and increased portability
in the future. Maybe the people who have worked with capsicum(4) or have
Am 11. Juni 2016 12:38:34 MESZ, schrieb Wolfgang Zenker
:
> Hi,
>
> * Domagoj Stolfa [160611 02:47]:
> > Has there been discussion on the OpenBSD's pledge going into the
> FreeBSD
> > kernel as an atomic syscall or as a MAC plugin?
>
> I
Hi,
* Domagoj Stolfa [160611 02:47]:
> Has there been discussion on the OpenBSD's pledge going into the FreeBSD
> kernel as an atomic syscall or as a MAC plugin?
I don't remember any discussions about this, but looking at OpenBSDs
plege(2) manpage, isn't this something
13 matches
Mail list logo